Re: [ql-users] I'm home, dear.

2005-01-13 Thread Joachim Van der Auwera
Wolfgang Lenerz wrote:
On 12 Jan 2005 at 23:46, Marcel Kilgus wrote:

Example: allocate the memory before the execution of the job with the
job as the owner. It will get freed automatically on removal of the
job. And how do you know that the memory is not valid anymore? Easy,
the job-ID won't be valid anymore.
Correct. Except that I initially planned to have some kind of linked list. If the memory 
just goes away because the job is removed the list will be broken.
There are several solutions I not sure yet which one is best.
The solution is very simple. When you allocate memory in QDOS, the 
header includes a few useful things. One of these is the owning job id 
(to know what to release when the job is removed or stops). Another is a 
pointer to a cleanup routine (in syslib I allow this to be set by the 
user,, very handy).
Anyway, the combination of these two long words can be used to make sure 
everything is cleaned up properly.

Joachim
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Wolfgang Lenerz
On 13 Jan 2005 at 9:24, Joachim Van der Auwera wrote:

> 
> The solution is very simple. When you allocate memory in QDOS, the 
> header includes a few useful things. One of these is the owning job id 
> (to know what to release when the job is removed or stops). Another is a 
> pointer to a cleanup routine (in syslib I allow this to be set by the 
> user,, very handy).
> Anyway, the combination of these two long words can be used to make sure 
> everything is cleaned up properly.

This sounds good, thanks!

Wolfgang

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Rich Mellor
On Thu, 13 Jan 2005 08:14:30 +0100, Wolfgang Lenerz  
<[EMAIL PROTECTED]> wrote:

On 12 Jan 2005 at 21:22, P Witte wrote:
LOAD win1_prg_fred_bas: REMark Load a program
SAVE: REMark Save the same program
"win1_prg_fred_bas" is the Save Name as far as Im concerned as I dont  
know
what else to call it. The Save Path (or directory) here is win1_prg.
Right, I wasn't even aware of that possibility!
I've had a quick look, this seem to be an Sbasic specific feature, it
doesn't exist in Superbasic (nor, I think in TK II, but could somebody
check?)..
Yes, this was introduced in smsq/e and is not even present in Minerva.
Perhaps, in that case, it should be kept separate from the home dir and
a simple function should return that name? The name also seems to be
limited to 36 bytes, something I'd like to avoid for the Homedir thing.
Just on a side note - why does everyone refer to 36 bytes as the filename  
length?

It is 41 (including the device name), or 42 if over a network server (eg.  
n2_win1_test_bas)


--
Rich Mellor
RWAP Services
26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ
http://www.rwapservices.co.uk/
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Rich Mellor
On Thu, 13 Jan 2005 08:14:30 +0100, Wolfgang Lenerz  
<[EMAIL PROTECTED]> wrote:

On 12 Jan 2005 at 23:46, Marcel Kilgus wrote:
P Witte wrote:
> I never knew that I wanted a current directroy,
I didn't know that you want one either, but I know that *I* would like
one ;-)
> However, this is a much more ambitious project than a mere home
> directory affair.
Actually I think it doesn't amount to much more work.
> You have to alter the device driver to cater for it too.
Hm, which? I don't propose that every device driver should know about
the current directory but that there could be a new device like
"home_" or something that did specifically include the current-path,
exe-path or whatever.
Yes, there could be, but that exceeds the simple home/current dir thing.  
The advantage
is that we can build this in a modular way. First I make the home dir  
thing & alter EX etc
to take advantage of it. Then YOU alter Qpac2 (and Cueshell?) to take  
advantage of it
(Ha!).
Things like FileInfo II should probably also be altered. I don't know  
right now whether
the code is available?
I must admit that I do like the proposal of having a new device driver  
which would look up the current directory in the Thing directories list.   
This would make it a lot easier to use with existing programs, especially  
as you could use DATA_USE "home_" :-)

The keywords for EX etc would still need to be updated to set up the data  
block within the THING (presumably so could BT_EXEC etc).  However, it  
does mean that OPEN, LBYTES etc would not need to be updated and therefore  
would cut down the overall amount of work required.

<>
--
Rich Mellor
RWAP Services
26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ
http://www.rwapservices.co.uk/
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Rich Mellor
On Thu, 13 Jan 2005 08:14:30 +0100, Wolfgang Lenerz  
<[EMAIL PROTECTED]> wrote:

It will be set up as a "thing" (since I don't think we have found any  
other
satisfactory solution for compiled Basic).
For each job, the thing should contain:
the complete filename
the dir whence it came from (home dir)
the current dir which will initially be the home dir

facilities should exist to
set the complete filename. This will also set the home dir and current
dir.
get the filename, home dir and current dir.
set the current dir (either directly or by ddup, ddown?)
get the length of the file/dir names (this would only be of interest
 if *somebody* actually gets around to implementing some form of
long file names).
set a default filename for a job with a certain name

Wolfgang - my interest has started to be inspired :-)
This scheme sounds a very good idea.
We need to agree which commands will set up the current filename.
Suggest: EX,EXEC,EW,EXEC_W,LOAD,LRUN,HOT_LOAD,HOT_RES,HOT_RES1
Turbo: EXECUTE,EXECUTE_A,EXECUTE_W
I do think however, that the easiest way for programs to access these  
would be through:

a) new commands to set and read the values
b) a new device(s) to read the home and current directory, so that you can  
use OPEN "home_config"
   suggest these are
	home_
	my_

I think that the device is necessary to ensure that these new facilities  
could be used within existing programs if you want.

--
Rich Mellor
RWAP Services
26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ
http://www.rwapservices.co.uk/
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Geogwilt
In a message dated 12/01/05 12:45:10 GMT Standard Time, 
[EMAIL PROTECTED] writes:

> 
> (...)
> >Only problem here is that if an existing program is called with the home  
> >dir on the stack - the program will not tidy up the stack correctly since  
> >it does not know to remove the extra bytes (I think though could be  
> >wrong here)
> 

I think my recent programs do clear anything on the stack since I set the 
bootom to (A6,A5).

> Well the first thing the prog would have to do would be to precess the 
> string 
> anyway, and copy it somewhere safe...
> 
> >However, how would a program aware that the home dir might be higher up  
> >the stack cope with this - for example, some programs MAY require an empty  
> 
> >string to be passed as the command string.  Guess if there is a special  
> >identifier word before the home dir string, this would overcome this  
> >problem.
> 
> Simple:
> 
> word length of command string (may be 0 if no command string)
> command string
> word length of home dir (may be 0 if no home dir)
> 

Anything new on the stack woould have to be after the channel IDs and the 
proper parameter string. It would be in the space between (A7)  + C + P and 
(A6,A5), where C is the space taken by channels ( word at A7 * 4 + 2) and P is 
the 
space taken by the parameter string ( word at (A7 + P) * 1 + 2 + 1 if the 
position is odd). Any new item can thus easily (?) be detected by new programs 
and 
will almost certainly be ignored by old ones.

> 
> 
> But really, putting this after the command string is a nono unless you solve 
> 
> the problem for compiled progs!
> 
> Wolfgang
> ___

I would imagine that OPTION_CMD$ in Turbo TK code does just take the 
parameter string and not any extra bytes following it on the stack and so 
existing 
(and new) Turbo compiled programs should still work.


George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QL filename length revisited

2005-01-13 Thread Geogwilt
In a message dated 12/01/05 06:08:07 GMT Standard Time, 
[EMAIL PROTECTED] writes:

> 
> I have a question here.
> 
> Currently, the way directories are handled is by making a directory a 
> somewhat special file (file type -1, IIRC).
> 
> Apart from that, though,a  directory ia a simple file that can be 
> accessed more or less like any file.
> 
> Directories contain an "entry" per file referenced in that directory.
> Part of the entry is the filename of the file.
> However, and that is where the original designers made a design 
> decision we all regret today, this filename is the ENTIRE name of the 
> file, (minus the device name).
> 
> Example: you have a file called "win1_subdir1_subdir2_subdir3_myfile"
> 
> The filename as contained in the entry in subdir3_ for this file will be:
> "subdir1_subdir2_subdir3_myfile".
> 
> As you can see, we are quickly getting to the 36 chars limit since that is 
> the most space a filename can take in the directory file entry.
> 
> Wouldn't the most simple way to get around the name length limitation 
> be that each directory holds only the filename itself?
> 
> Of course, each name on each directory level  would still be limited to 
> 36 chars, but something like:
> 
> win1_verylongsubdirname1_verylongsubdirname2_verylongsubdirnam
> e3_verylongsubdirname4_verylongsubdirname5_prettylongfilename
> 
> would be possible.
> Perhaps the directory should be a new file type (-5 ot whatever) to 
> show that this is a new type of directory.
> 
> Legacy applications wouldn't work in this scheme. But, let's face it, 
> whatever the scheme you are going to implement, they won't work 
> (one, because the finale filemane will be too long anyway, two because 
> they can't access new directories anyway).
> 
> 

I had the impression that directories in QDOS were notional, not real. That 
is, each file, with its full name, exists on the medium whether or not a 
directory has been "made". Thus, if win1_op_f1 and win1_op_f2 are two files on 
win1_ 
they will immediately appear in a directory if win1_op is made a directory by

   make_dir win1_op.

The original files are totally unchanged, but a new file with type 255 (or 
-1) and name win1_op is added to win1. This has the effect, through software, 
of 
all files with names starting win1_op_ being treated as though they were in a 
directory called win1_op.

If this is true, I don't see how a filename can be shortened simply because 
it has notionally been put in a directory.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Geogwilt
In a message dated 12/01/05 10:57:32 GMT Standard Time, 
[EMAIL PROTECTED] writes:

> 
> >On 11 Jan 2005 at 22:19, Rich Mellor wrote:
> >(...)
> >>1) Older programs which would expect (a6,a5) to point to the command
> >>string at the top of the data area.  If we were to adopt this scheme,  
> >>then
> >>a lot of existing programs would immediately not be able to get at any
> >>parameters passed to them.  We do not have the software authors or  
> >>sources
> >>to enable us to amend existing programs or re-write them.  I guess we
> >>could overcome this by amending the setup job code to have (A5,A0) (?)
> >>point to the location of the home directory
> >
> >No. Let a6,a5 point to where it usually points, i.e. the command string.  
> >Finding
> >the home dir after the command string (for a prog aware of this) is  
> >trivial.
> 
> I agree that (a6,a5) MUST point to the command string - otherwise existing  
> programs may have a problem on the new system as they will expect the  
> command string to be here not a little bit further down the stack.
> 

Actually (A6,A5) points to the END of any parameter string and so after any 
channel IDs on the stack. A7, on the other hand, poonts to the channel IDs and 
parameter list. It is important that if anything extra is put on the stack it 
appears AFTER the parameter list. Most existing programs would simply ignore 
the extra bytes.

The first programs I wrote totally ignored the possibility of parameter 
lists. Hence the bottom of my stack was at least 4 bytes higher than it needed 
to 
be. More recent programs set the stack to (A6,A5) after dealing with any 
parameter list so I can use the full space available for the stack.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Geogwilt
In a message dated 12/01/05 21:36:28 GMT Standard Time, 
[EMAIL PROTECTED] writes:

> 
> Since EX already uses this technique to add the user-specified data on top
> of the (programmer-specified) dataspace, it didnt seem unreasonable to me to
> extend the concept to include the home directory string. As it happens,
> (a6,a5) would then point to the magic marker I suggested in a previous
> mail - or into the void where, as I mentioned, QLib had no business to poke
> around.
> 

I sincerely hope that (A6,A5) would continue to point to the absolute end of 
everything in any future change. As I said elsewhere, you can still find extra 
bytes on the stack in the space between (A6,A5) and the end of the parameter 
list.

Goerge
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread P Witte
Wolfgang Lenerz writes:

[Save Name]

> Right, I wasn't even aware of that possibility!
>
> I've had a quick look, this seem to be an Sbasic specific feature, it
> doesn't exist in Superbasic (nor, I think in TK II, but could somebody
> check?)..

Yes, its strictly SMSQE only. Nice little job for some Qdos aficionado to
add the facility to SuperBasic?
<>

Per

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread P Witte
Wolfgang Lenerz writes:

> > > Your idea sounds excellent. Instead of my bicycle you and Wolfgang
> > > have produced a Mercedes. I am in favour (as long as I dont have to
> > > produce it ;)
> >
> > Damn, that was my precondition, too! ;-) But it does start to sound
> > like a worthwhile job.
>
> You will notice that (contrary to the long file names topic) I didn't ask
> a question, but made a suggestion. This implies that I'm quite
> willing to do that stuff...

Bravo to you!

> I'm not promising anything quick, though.

(Wasnt that what I said two years ago?  ;)

> Can we more or less agree on the following:
>
> ---
> It will be set up as a "thing" (since I don't think we have found any
> other satisfactory solution for compiled Basic).

"We" havent really tried, but ok

> For each job, the thing should contain:
> the complete filename
> the dir whence it came from (home dir)
> the current dir which will initially be the home dir
>
> facilities should exist to
> set the complete filename. This will also set the home dir and current
> dir.
> get the filename, home dir and current dir.
> set the current dir (either directly or by ddup, ddown?)

Both. By why not re-use the DUP & DDOWN code as a general utility to work on
any filename string, given the string's location? Suggest the new Sbasic
keywords be called UD, DD and CD (CD -> Change dir, ie set a new start
string) ie, something quick and simple (though admittedly a two char name is
potentially dangerous)

[Note: Since we're still in "brainstorming mode" I reserve the right to
make /outrageous/ and even downright /stupid/ suggestions without being
smirked at at future QL shows, ok?  ;o]

> get the length of the file/dir names (this would only be of interest
>  if *somebody* actually gets around to implementing some form of
> long file names).

Yes! Ie, no LEN, it has to be a system call

> set a default filename for a job with a certain name

No. I dont see the point. They can just use PROGD$ as now.
<>

Per

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread P Witte
Wolfgang Lenerz writes:

> Sorry  but A6,A5 does indeed point to the *end* of the command string at
> least when the job is invoked by EX it doesn't point to any data area

Yes, the documentation is a bit misleading here.

<>
> Apart form that, I think we agree on the Ex mechanism.
>
> (...)
> >
>
> > QLib does, of course, know about the space taken up by the channels and
> > command string and so, if it likes, can scribble all over it. It cant
> > scribble over "my" area as, as far as it is concerned, that memory
> > doesnt belong to it.
>
> So a6,a5 would stay where it is.
>
> > I hope this clarifies matters. However, the point is moot at present,
> > since it seems that at a different solution is currently the favourite.
>
> Could you agree to it?

The only power a volunteer has in cases such as these is to give or to
withhold his work, so of course I agree ;)

But do you agree that the concept of stacking information on top of the
stack, as outlined invarious mails in recent days, is theoretically
feasable?

Per

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread P Witte
Marcel Kilgus writes:

<>
> > However, this is a much more ambitious project than a mere home
> > directory affair.
>
> Actually I think it doesn't amount to much more work.

Perhaps it is a separate piece of work altogether? Afterall, why not have as
many current directories as you like, from 0..n? This could be a separate
System Service altogether.

> > You have to alter the device driver to cater for it too.
>
> Hm, which? I don't propose that every device driver should know about
> the current directory but that there could be a new device like
> "home_" or something that did specifically include the current-path,
> exe-path or whatever.

You did mention OPEN in an earlier mail...

> > It also implies that Qdos is left out in the cold and that
> > programmers who want to make their programs run under Qdos will have
> > to make a considerable effort to achieve that.
>
> Hmm, why? Currently I don't see anything in my proposal that is
> strictly SMSQ/E specific.
> Thought I am beginning to hate QDOS compatibility, just out of spite.

As above. Another thing with Things is that every program will have to carry
the code to scan for the THING Thing (apologies to the scores of avid
readers following this thread for this apparent mumbo-jumbo ;) if they want
to stay Qdos compatible. Not a big deal but the word "bloat" does tend to
insinuate itself..

> > However, my thinking goes: If all the Homedir is wanted for is to find
> > the location of some config file (as will often be the case) then the
> > space taken up by the Homedir string could simply be re-used as a
> > Current dir.
>
> Well, this is what I call a "hack". Nothing wrong with that per se, I
> do that a lot. But if I design a *new* OS interface it is usually not
> the way I want to go, at least if I can't help it.
<>

No, extending the CDB was a hack, and not a pretty one either, but quite
servicable. My proposal is an extension of an existing facility, namely
stacking an additional parameter above the command line, where only
cognizant programs will know to look for it. The concept is widely used
throughout Qdos/SMSQE. The only hack involved would be to get QLib to find
it, and QLib is going to have to be hacked almost whatever solution is
chosen.

> >> I don't see memory fragmentation as a problem. The memory block will
> >> start its life with the memory block for the job and will end its life
> >> along with it. No fragmentation really.
> > If you say so. You havent explained how you would set about it.
>
> Example: allocate the memory before the execution of the job with the
> job as the owner. It will get freed automatically on removal of the
> job. And how do you know that the memory is not valid anymore? Easy,
> the job-ID won't be valid anymore.

The fragmentation I suggested would be due to the fact that whenever a job
dies there will be three holes in memory instead of just two. However, I
concede that this probably is insignificant.

Per

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread P Witte
Wolfgang Lenerz writes:

<>
> > Other thought: make the job use the thing, which in turn reserves the
> > memory. On removal the thing will be informed and can deal with that.
> > Just a thought, I am NO expert on things.
>
> But this is entirely correct - it would just mean that the thing would
> have to be used continuously by that job.

Is there any reason why the job cant be born as a confirmed Thing user, ie
it doesnt have to take any specific action to use the Thing when it starts
up. Let the setup routine (currently EX) sort it all out before handing over
to the job?

Per

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread P Witte
Wolfgang Lenerz writes:

> > Sorry if I misunderstood.
> (or I did!)

It is easier to misunderstand that otherwise. Weve all been doing a lot of
that during this and other discussions. Very frustrating, but it cant be
helped. As long as we get some results AND stay positive very little else
matters ;)

> > Executable Things that were set up using HOT_RES
> > and family would have access to the filename, and every instance of of
> > the Thing that was executed via EXEP could inherit that filename.
>
> This means that the thing will, indeed, have to have some kind of
> "default" facility, as envisaged earlier.

No, no:

ERT HOT_RES('x', 'win1_psion_XChange', 'X')

The file name is there! Thats the one to store somewhere and propagate to
every instance of that job.

<>

Per

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QL filename length revisited

2005-01-13 Thread Jérôme Grimbert
[EMAIL PROTECTED] wrote:
In a message dated 12/01/05 06:08:07 GMT Standard Time, 
[EMAIL PROTECTED] writes:


I have a question here.
Currently, the way directories are handled is by making a directory a 
somewhat special file (file type -1, IIRC).

Apart from that, though,a  directory ia a simple file that can be 
accessed more or less like any file.

Directories contain an "entry" per file referenced in that directory.
Part of the entry is the filename of the file.
However, and that is where the original designers made a design 
decision we all regret today, this filename is the ENTIRE name of the 
file, (minus the device name).

Example: you have a file called "win1_subdir1_subdir2_subdir3_myfile"
The filename as contained in the entry in subdir3_ for this file will be:
"subdir1_subdir2_subdir3_myfile".
As you can see, we are quickly getting to the 36 chars limit since that is 
the most space a filename can take in the directory file entry.

Wouldn't the most simple way to get around the name length limitation 
be that each directory holds only the filename itself?

Of course, each name on each directory level  would still be limited to 
36 chars, but something like:

win1_verylongsubdirname1_verylongsubdirname2_verylongsubdirnam
e3_verylongsubdirname4_verylongsubdirname5_prettylongfilename
would be possible.
Perhaps the directory should be a new file type (-5 ot whatever) to 
show that this is a new type of directory.
Why not. It seems to make sense to me.
Legacy applications wouldn't work in this scheme. But, let's face it, 
whatever the scheme you are going to implement, they won't work 
(one, because the finale filemane will be too long anyway, two because 
they can't access new directories anyway).
We could even do better.
We have two kind of filesystem: the floppy and the harddisk.
Maintaining floppy compatibility is essential.
If we could store the EXEC information on DOS format, things would be 
simple, and I would push for the DOS format, not because it is DOS, but 
because it is so wide spread.
So far, let's keep the QL floppy format. (We could also devise a new 
QL5C floppy format, but only updated system could read it, so that's not 
so useful.)

BUT, the harddisk does not need to be exchanged with another system.
Therefore, we can do as we want on a harddisk partition.
As long as we are able to copy the harddisk file to the floppy, who care 
how the file is stored on the harddisk.
The filenaming issue can easily been dealed with by the user at copy time.




I had the impression that directories in QDOS were notional, not real. That 
is, each file, with its full name, exists on the medium whether or not a 
directory has been "made". Thus, if win1_op_f1 and win1_op_f2 are two files on win1_ 
they will immediately appear in a directory if win1_op is made a directory by

   make_dir win1_op.
The original files are totally unchanged, but a new file with type 255 (or 
-1) and name win1_op is added to win1. This has the effect, through software, of 
all files with names starting win1_op_ being treated as though they were in a 
directory called win1_op.
Correct. The filename is stored at the beginning of the file itself, in 
the first sector given by the index.
I currently assume that make_dir, when creating the directory either:
 - refuse the creation if somefile already exists
 - move the mapping entries from the current directory (/root directory 
or an already existing directory) to the new directory.

Now, the problem is that the stored information at the beginning of the 
file is not the filename, but the pathname (the device part being 
removed anyway).
That why I always think that a full pathname (device included) can be 
longer that 41 char: win1_+36 char = 41, but n1_dev1_+36 is already bigger!
If we could simply change the make_dir routine, as well as the name 
building code (you have to remember which directories you went through),
the system could very well provide an unlimited pathname (well, at 
worst, a 32767-char pathname... with at least a directory every 36 char)
But then we could as well force a directory separator, to ease parsing 
as well as other things: what about a real '/' ?
The obvious problem with / is that simple expression like win1_eort/ekr 
must be put inside quote to avoid floating evaluation by the basic.
SAVE "win1_eort/ekr", I can live with that!

A note for any filesystem designer: the partition size is currently 
limited to a, by today standard, very small size. If we could avoid to 
resort to big chunk, that would be very good. (give us back a 512 sector 
allocation unit, please!)
(What about a 32 bits indexing instead of the limited one we have today: 
32 bits of 512 bytes sectors should be big enough for a single 
partition, that's about 4 TBytes)


___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


[ql-users] QPC Keyboard

2005-01-13 Thread ian . pizer
Hi Experts

When I use QPC2v312 via XP my keyboard is jumbled. e.g.x>y and z>x and much
more, so using BASIC etc. is a bore. My setup is as follows: All is in French
(XP etc.) The Language and Keyboard in XP is Français(Suisse). The actual
KB is Dell with some accent keys at right of P and L. The words on the KB
are in English.

I have tried changing the kb language in XP to Anglais(Etats-Unis), that
is English(USA), and also English(UK), then running QPC but the kb result
is still jumbled. This problem has always existed with older QPCs and probable
with Windows 98.

Is there a way of modifying the keyboard within QPC so kb works properly?
In otherwords is there a kb driver for QPC which would help. If not, why
not (hee hee!)

Cheers,

Ian Pizer, 49 ch. Machery, 1292 Chambesy, Geneva, Switzerland
e-mail [EMAIL PROTECTED]  Tel. 41227581410

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QPC Keyboard

2005-01-13 Thread Wolfgang Uhlig
When I use QPC2v312 via XP my keyboard is jumbled. e.g.x>y and z>x and  
much
more, so using BASIC etc. is a bore. My setup is as follows: All is in  
French
(XP etc.) 
Only to be sure, you do have configured QPC to french, haven't you?
Wolfgang
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: Re: [ql-users] BMP files etc

2005-01-13 Thread dilwyn.jones
> Dilwyn, with all the stuff that you are providing on your www site maybe 
> you should also consider an FTP repository. In that way all the files 
> available are readily accessible for download.
> 
> FTP came before HTTP and was designed for file access.  Although the 
> latter seems now to be more popular as users are more used to accessing 
> from a web site.
> 
> -- 
> Malcolm Cadman
I've never set up an FTP site and would need help and advice to get it going, 
but it's something I'd consider. I've been very lucky with the Freeola UK6 
site, it's reliable, has masses of free space and the only real restriction 
they place on you is that everything must be "visible", i.e. pages anyone can 
read or files anyone can download, you mustn't use it as a private file store. 
I guess they make their money from users dialling up.

Can you point me a source of information on getting and setting up an FTP site?

Dilwyn Jones

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: Re: [ql-users] QL filename length revisited

2005-01-13 Thread dilwyn.jones
> What I thought you were saying was a method by which you were 
> integrating the win drive into a network with other computers, in terms 
> of accessing the files.  I am assuming that you are allowed to log in a 
> portable PC with QPC2 installed onto a PC network where you work.
> 
> -- 
> Malcolm Cadman
We are only a small 16-staff company with 4 office terminals currently on the 
network, although it is straightforward to add a few more. We are allowed to do 
reasonable things as long as we use the virus checkers and don't recklessly put 
the network at risk. I'm one of the two of us who look after the computers 
(good job I like PCs eh?) so I simply ask myself permission ;-)

Actually, I take care to virus scan and the software is pretty rock solid here. 
I've been caught out enough times by viruses and all the various other problems 
in my time to avoid unnecessary risk.

I do sometimes alter the WIN and DOS path names to access one of the other 
computers over the network (classic is that the boss's printer is the only one 
I can  print to from QPC2, the others have no DOS mode and simply ignore 
QPC2!). My QXLWINManager program comes in handy to rememeber and set up these 
long winded network path names, so it's quite practical to be running as many 
devices as you want and hot-swap the path names with WIN_DRIVE, DOS_DRIVE etc.

My computing world seems to be a complex interaction of PC and QPC2. It used to 
be pretty clear cut - use the QPC2 for whatever I could and use Windows for 
everything else (usually scanning and email/internet) but what with Marcel's 
work on TCP/IP from QPC2 it's getting a little less clear cut than it used to 
be!

Now all I need to do is persuade either QPC2 or PC to answer the phone for me 
to filter out the whacky sales calls getting in the way of the real customers! 
Perhaps I could make up a stupid CD of prank sounds for QPC2's CD Player to 
play to the endless telephone salesmen while I leave them on hold!

(Before anyone says it, we tried TPS, judging by the accents many of these 
calls are probably from foreign call centres anyway...Path Name Length 
error...wonder if I could get away with saying "Sorry I only speak Welsh" to 
them?).

Dilwyn Jones

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QPC Keyboard

2005-01-13 Thread ian . pizer
That is a great idea - how do you do it? My QPC has no configure block.

>-- Message original --
>To: [EMAIL PROTECTED]
>Subject: Re: [ql-users] QPC Keyboard
>Date: Thu, 13 Jan 2005 15:23:55 +0100
>From: "Wolfgang Uhlig" <[EMAIL PROTECTED]>
>Cc: 
>Reply-To: [EMAIL PROTECTED]
>
>
>> When I use QPC2v312 via XP my keyboard is jumbled. e.g.x>y and z>x and
> 
>> much
>> more, so using BASIC etc. is a bore. My setup is as follows: All is in
> 
>> French
>> (XP etc.) 
>
>Only to be sure, you do have configured QPC to french, haven't you?
>Wolfgang
>___
>QL-Users Mailing List
>http://www.q-v-d.demon.co.uk/smsqe.htm

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: Re: [ql-users] I'm home, dear.

2005-01-13 Thread dilwyn.jones
> Can we more or less agree on the following:
> 
> ---
> It will be set up as a "thing" (since I don't think we have found any other 
> satisfactory solution for compiled Basic).
> For each job, the thing should contain:
> the complete filename
> the dir whence it came from (home dir)
> the current dir which will initially be the home dir
> 
> facilities should exist to
> set the complete filename. This will also set the home dir and current 
> dir.
> get the filename, home dir and current dir.
> set the current dir (either directly or by ddup, ddown?)
> get the length of the file/dir names (this would only be of interest
>  if *somebody* actually gets around to implementing some form of 
> long file names).
> set a default filename for a job with a certain name
> 
> --
> 
> Anything else?
> 
> As usual, relatively few people have commented on this...
That looks quite good to me.

My primary interest was simply being able to fetch the name of the location the 
program was executed from. I wasn't fussed at all about the method, and the 
other aspects are simply desirable rather than essential as far as I'm 
concerned.

It sounds as if you are moving (or hoping to move) towards the end of 
discussion and on to some programming. May I wish you all the best for this 
project.

Dilwyn Jones

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QPC Keyboard

2005-01-13 Thread Wolfgang Uhlig
That is a great idea - how do you do it? My QPC has no configure block.
Oh, hardly can't  believe that you don't know:
double clicking on your QPC.exe while holding pressed the Shift key will  
bring you
into the config menu of QPC/SMSQ/E, where you can configure lots of things  
among which
the language/keyboard layout.

Wolfgang
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QL filename length revisited

2005-01-13 Thread Marcel Kilgus
Jérôme Grimbert wrote:
> We have two kind of filesystem: the floppy and the harddisk.
> Maintaining floppy compatibility is essential.

Floppies don't need such long paths anyway.

> If we could store the EXEC information on DOS format, things would be
> simple, and I would push for the DOS format, not because it is DOS, but
> because it is so wide spread.

Just an unrelated note to the DOS long-filename-hack: They had to do
this because a single file name was limited to only 8 characters. We
have 36 characters to work with, which is much less of a burden. So I
don't see the need for something similar.

> BUT, the harddisk does not need to be exchanged with another system.
> Therefore, we can do as we want on a harddisk partition.

Quite right.

> Correct. The filename is stored at the beginning of the file itself, in
> the first sector given by the index.

Actually that is only true for Microdrives. Not sure about Floppy, but
definitely not QLWA drives. The header space is there but empty.

> That why I always think that a full pathname (device included) can be
> longer that 41 char: win1_+36 char = 41, but n1_dev1_+36 is already bigger!

Because n is really a character device. The physical path that will
get accesses by the server is still only 41 characters.

Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


[ql-users] Cold callers

2005-01-13 Thread Tony Firshman
On  Thu, 13 Jan 2005 at 15:47:22,  wrote:
(ref:
<[EMAIL PROTECTED]>)


>Now all I need to do is persuade either QPC2 or PC to answer the phone
>for me to filter out the whacky sales calls getting in the way of the
>real customers! Perhaps I could make up a stupid CD of prank sounds for
>QPC2's CD Player to play to the endless telephone salesmen while I
>leave them on hold!

I will not forget the guy on R4 You and Yours who said his approach was
to sound very interested.  "Hold on a minute, I will get my wife.  I
know it is just what she wants".  He then puts the phone on hold, and
checks every once in a while.  Apparently his record was 45 minutes.
The brilliant thing is that not only does the caller pay a fortune, but
he cannot pester anyone else for that time.
I wish I had the patience to do that.

I forget who it was now, but a friend or client has a long answer
machine announcement, and they -never- actually answer that phone.
They point out on tape that they do not want to hear from non-customers
(ie prize announcements and the like).  They then filter from that and
only give the -real- number to people they want to hear from.

Sounds brilliant to me, but you do need at least one other number (plus
maybe another for fax).
>
>(Before anyone says it, we tried TPS,
TPS?
> judging by the accents many of these calls are probably from foreign
>call centres anyway...Path Name Length error...wonder if I could get
>away with saying "Sorry I only speak Welsh" to them?).
What language would you say that in (8-)#

Tony
-- 
 QBBS (QL fido BBS 2:252/67) +44(0)1442-828255
 tony@.co.uk  http://firshman.co.uk
   Voice: +44(0)1442-828254   Fax: +44(0)1442-828255
TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] BMP files etc

2005-01-13 Thread James Hunkins
Actually I personally prefer the way you have it now Dilwyn.  It works 
great and you are able to give descriptions with everything.  An FTP 
site is fine for massive file downloads or looking for particulars.  
But it depends on file names and folder hierarchy to let people know 
what stuff is.  And not all the files that you and everyone offers have 
the most descriptive names.

I would be asking what the advantage to setting up an FTP site actually 
is, other than a personal preference of someone, before you go to all 
the work of doing it.

There might be a good reason but I can't think of one, at least for 
your files.

Cheers,
jim
On Jan 13, 2005, at 7:31 AM, <[EMAIL PROTECTED]> wrote:
Dilwyn, with all the stuff that you are providing on your www site 
maybe
you should also consider an FTP repository. In that way all the files
available are readily accessible for download.

FTP came before HTTP and was designed for file access.  Although the
latter seems now to be more popular as users are more used to 
accessing
from a web site.

--
Malcolm Cadman
I've never set up an FTP site and would need help and advice to get it 
going, but it's something I'd consider. I've been very lucky with the 
Freeola UK6 site, it's reliable, has masses of free space and the only 
real restriction they place on you is that everything must be 
"visible", i.e. pages anyone can read or files anyone can download, 
you mustn't use it as a private file store. I guess they make their 
money from users dialling up.

Can you point me a source of information on getting and setting up an 
FTP site?

Dilwyn Jones
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QPC Keyboard

2005-01-13 Thread ian . pizer
Terrific. What ignorance on my part. I tried as you said but that does nothing.
Maybe because of Windows XP?

>-- Message original --
>To: [EMAIL PROTECTED]
>Subject: Re: [ql-users] QPC Keyboard
>Date: Thu, 13 Jan 2005 17:00:21 +0100
>From: "Wolfgang Uhlig" <[EMAIL PROTECTED]>
>Cc: 
>Reply-To: [EMAIL PROTECTED]
>
>
>> That is a great idea - how do you do it? My QPC has no configure block.
>Oh, hardly can't  believe that you don't know:
>
>double clicking on your QPC.exe while holding pressed the Shift key will
> 
>bring you
>into the config menu of QPC/SMSQ/E, where you can configure lots of things
> 
>among which
>the language/keyboard layout.
>
>Wolfgang
>___
>QL-Users Mailing List
>http://www.q-v-d.demon.co.uk/smsqe.htm

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QPC Keyboard

2005-01-13 Thread Rich Mellor
On Thu, 13 Jan 2005 20:15:40 +0100, <[EMAIL PROTECTED]> wrote:
Terrific. What ignorance on my part. I tried as you said but that does  
nothing.
Maybe because of Windows XP?
Nope works here - you might not be holding down the shift key long enough.
You might need to left click the QPC2 icon first and then hold down shift  
key whilst you double click the icon.
Otherwise, Windows might try to do the double click on more than one icon.

Otherwise, you can use MenuConfig on the smsq.e bin file.
--
Rich Mellor
RWAP Services
26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ
http://www.rwapservices.co.uk/
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: Re: [ql-users] I'm home, dear.

2005-01-13 Thread Wolfgang Lenerz
On 13 Jan 2005 at 15:52, [EMAIL PROTECTED] wrote:

> It sounds as if you are moving (or hoping to move) towards the end of 
> discussion and on to some programming. 
>May I wish you all the best for this project.


Thanks -I'll need it.

Wolfgang

www.scp-paulet-lenerz.com

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Wolfgang Lenerz
On 13 Jan 2005 at 11:59, P Witte wrote:

(...)
> 
> > I'm not promising anything quick, though.
> 
> (Wasnt that what I said two years ago?  ;)

I  *won't* take that long, though!
(...)
> > It will be set up as a "thing" (since I don't think we have found any
> > other satisfactory solution for compiled Basic).
> 
> "We" havent really tried, but ok

Go ahead!!!
(...)

> Both. By why not re-use the DUP & DDOWN code as a general utility to work 
on
> any filename string, given the string's location? Suggest the new Sbasic
> keywords be called UD, DD and CD (CD -> Change dir, ie set a new start
> string) ie, something quick and simple (though admittedly a two char name is
> potentially dangerous)

NOT trivial.

> [Note: Since we're still in "brainstorming mode" I reserve the right to
> make /outrageous/ and even downright /stupid/ suggestions without being
> smirked at at future QL shows, ok?  ;o]

Ok, we'll just smirk here, then...

> > get the length of the file/dir names (this would only be of interest
> >  if *somebody* actually gets around to implementing some form of
> > long file names).
> 
> Yes! Ie, no LEN, it has to be a system call
> 
> > set a default filename for a job with a certain name
> 
> No. I dont see the point. They can just use PROGD$ as now.

No, I thought about hot_rext'd progs.

To reacp:

When you exec an executable  thing from a hotkey, there is no way you'll set 
the home dir for that.
So, I proposed the following workaround: when that prog tries to get its 
homedir, this will fail (sinc eit wans't set for that prog)..
In such a case, the home thing should see whether there is a defaiult home 
dir set for a prog with that name, and pass that default home dir back.
Perhaps hot_rext could even set that default dir, instead of this being done 
by the user explicitly, but this I DON'T promise, I'll have to see how 
feasible that would be.

Wolfgang

www.scp-paulet-lenerz.com

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Wolfgang Lenerz
On 13 Jan 2005 at 12:03, P Witte wrote:

(...)

> > This means that the thing will, indeed, have to have some kind of
> > "default" facility, as envisaged earlier.
> 
> No, no:
> 
> ERT HOT_RES('x', 'win1_psion_XChange', 'X')
> 
> The file name is there! Thats the one to store somewhere and propagate to
> every instance of that job.

How? Delve into the hotkey system?
Umph!
Wolfgang

www.scp-paulet-lenerz.com

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Wolfgang Lenerz
On 13 Jan 2005 at 12:01, P Witte wrote:
> > Could you agree to it?
> 
> The only power a volunteer has in cases such as these is to give or to
> withhold his work, so of course I agree ;)

No, if you have a better idea, I'm always listening.

> But do you agree that the concept of stacking information on top of the
> stack, as outlined invarious mails in recent days, is theoretically
> feasable?

Yes, of course. I hope I never implied anything different!
 It is actually what I had in mind when I first thatabout this. it's easy - 
but then I hit the Basic snag. And then Marcel talked about the current dir 
etc...
Wolfgang

www.scp-paulet-lenerz.com

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Wolfgang Lenerz
On 13 Jan 2005 at 11:56, P Witte wrote:
(...)
  (...)
> No, extending the CDB was a hack, and not a pretty one either, but quite
> servicable. My proposal is an extension of an existing facility, namely
> stacking an additional parameter above the command line, where only
> cognizant programs will know to look for it. The concept is widely used
> throughout Qdos/SMSQE. The only hack involved would be to get QLib to find
> it, and QLib is going to have to be hacked almost whatever solution is
> chosen.
>I hope not.
Sbasic, Turbo & qlib progs will simply have new basic commands giving thm 
access to the home dir.

Something like your excellent homed$ proposal

Wolfgang

> > >> I don't see memory fragmentation as a problem. The memory block will
> > >> start its life with the memory block for the job and will end its life
> > >> along with it. No fragmentation really.
> > > If you say so. You havent explained how you would set about it.
> >
> > Example: allocate the memory before the execution of the job with the
> > job as the owner. It will get freed automatically on removal of the
> > job. And how do you know that the memory is not valid anymore? Easy,
> > the job-ID won't be valid anymore.
> 
> The fragmentation I suggested would be due to the fact that whenever a job
> dies there will be three holes in memory instead of just two. However, I
> concede that this probably is insignificant.
> 
> Per
> 
> ___
> QL-Users Mailing List
> http://www.q-v-d.demon.co.uk/smsqe.htm
> 



www.scp-paulet-lenerz.com

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QL filename length revisited

2005-01-13 Thread Wolfgang Lenerz
On 13 Jan 2005 at 13:46, Jérôme Grimbert wrote:
(...)

> BUT, the harddisk does not need to be exchanged with another system.
> Therefore, we can do as we want on a harddisk partition.
> As long as we are able to copy the harddisk file to the floppy, who care
> how the file is stored on the harddisk.
> The filenaming issue can easily been dealed with by the user at copy time.

This is of course the "best" solution - change the win device driver entirely
for something better.

The reason I put the quotes around the "best" is that this is NOT trivial at
all.. - to be quite frank : I doubt we'll ever see it.

> > I had the impression that directories in QDOS were notional, not real. That
> > is, each file, with its full name, exists on the medium whether or not a
> > directory has been "made". Thus, if win1_op_f1 and win1_op_f2 are two files 
> > on win1_
> > they will immediately appear in a directory if win1_op is made a directory 
> > by
> >
> >make_dir win1_op.
> >
> > The original files are totally unchanged, but a new file with type 255 (or
> > -1) and name win1_op is added to win1. This has the effect, through 
> > software, of
> > all files with names starting win1_op_ being treated as though they were in 
> > a
> > directory called win1_op.
>
> Correct.

No. If you have a subdir called subdir1_ in win1_ and a file called file1 in
subdir1_, that file is NOT in the win1_ directory!

> The filename is stored at the beginning of the file itself, in
> the first sector given by the index.


> I currently assume that make_dir, when creating the directory either:
>   - refuse the creation if somefile already exists
yes
>   - move the mapping entries from the current directory (/root directory
> or an already existing directory) to the new directory.

yes it does that.

> Now, the problem is that the stored information at the beginning of the
> file is not the filename, but the pathname (the device part being
> removed anyway)
+ the filename
.
> That why I always think that a full pathname (device included) can be
> longer that 41 char: win1_+36 char = 41, but n1_dev1_+36 is already bigger!
yes.

> If we could simply change the make_dir routine, as well as the name
> building code (you have to remember which directories you went through),
> the system could very well provide an unlimited pathname (well, at
> worst, a 32767-char pathname... with at least a directory every 36 char)
> But then we could as well force a directory separator, to ease parsing
> as well as other things: what about a real '/' ?
> The obvious problem with / is that simple expression like win1_eort/ekr
> must be put inside quote to avoid floating evaluation by the basic.
> SAVE "win1_eort/ekr", I can live with that!

Again this will require so many changes that I doubt they will ever be made.

(...)


Wolfgang

www.scp-paulet-lenerz.com

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Wolfgang Lenerz
On 13 Jan 2005 at 12:04, P Witte wrote:
> Is there any reason why the job cant be born as a confirmed Thing user, ie
> it doesnt have to take any specific action to use the Thing when it starts
> up. Let the setup routine (currently EX) sort it all out before handing over
> to the job?

No reason at all other than my pigheadedness, in not seeing why a job would 
continue using a thing when it isn't needed any more.

Wolfgang.


www.scp-paulet-lenerz.com

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread Malcolm Cadman
In message <[EMAIL PROTECTED]>, Wolfgang Lenerz 
<[EMAIL PROTECTED]> writes


Can we more or less agree on the following:
---
It will be set up as a "thing" (since I don't think we have found any other
satisfactory solution for compiled Basic).
For each job, the thing should contain:
the complete filename
the dir whence it came from (home dir)
the current dir which will initially be the home dir
facilities should exist to
set the complete filename. This will also set the home dir and current
dir.
get the filename, home dir and current dir.
set the current dir (either directly or by ddup, ddown?)
get the length of the file/dir names (this would only be of interest
if *somebody* actually gets around to implementing some form of
long file names).
set a default filename for a job with a certain name
You are very good at drawing out the essentials of the discussion.
You may now get more comments from a wider range of users if you or 
others can give some practical examples of the disadvantages of the 
present method, and the advantages of the improved method.

--
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] BMP files etc

2005-01-13 Thread Malcolm Cadman
In message 
<[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] writes

Dilwyn, with all the stuff that you are providing on your www site maybe
you should also consider an FTP repository. In that way all the files
available are readily accessible for download.
FTP came before HTTP and was designed for file access.  Although the
latter seems now to be more popular as users are more used to accessing
from a web site.

I've never set up an FTP site and would need help and advice to get it 
going, but it's something I'd consider. I've been very lucky with the 
Freeola UK6 site, it's reliable, has masses of free space and the only 
real restriction they place on you is that everything must be 
"visible", i.e. pages anyone can read or files anyone can download, you 
mustn't use it as a private file store. I guess they make their money 
from users dialling up.

Can you point me a source of information on getting and setting up an FTP site?
At present I haven't set up one either. Probably when Phoebus gets back 
on the list he will have the know how and information.

I have two net accounts, one with Demon and one with AOL.
The Demon account has everything, I just haven't investigated it for 
FTP.

The AOL account gives an easy to use access to storing files via FTP as 
a part of the package.

Perhaps Rich will know more about this too, as he may have a fuller AOL 
account than mine.

In addition I have found it find it to be a handy way to get large files 
from one machine to another by using it as a store.  Upload from one 
computer and download on the other.

Of course the 'free' space available on AOL is limited.  Yet a fuller 
service would be the equivalent of having a large virtual drive.

A cost for dial-up accounts, yet easy for broadband and the like.
--
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QL filename length revisited

2005-01-13 Thread Malcolm Cadman
In message 
<[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] writes

What I thought you were saying was a method by which you were
integrating the win drive into a network with other computers, in terms
of accessing the files.  I am assuming that you are allowed to log in a
portable PC with QPC2 installed onto a PC network where you work.

We are only a small 16-staff company with 4 office terminals currently 
on the network, although it is straightforward to add a few more. We 
are allowed to do reasonable things as long as we use the virus 
checkers and don't recklessly put the network at risk. I'm one of the 
two of us who look after the computers (good job I like PCs eh?) so I 
simply ask myself permission ;-)
I figured that may be the case ... :-)
My work network is quite large, and I haven't yet been awarded a 
portable PC.  The network is now Windows XP Professional from middle of 
last year ( 2004 ).  Previously it was Windows 2000, and before that 
Windows 98.

Actually, I take care to virus scan and the software is pretty rock 
solid here. I've been caught out enough times by viruses and all the 
various other problems in my time to avoid unnecessary risk.
Yes, essential.
I do sometimes alter the WIN and DOS path names to access one of the 
other computers over the network (classic is that the boss's printer is 
the only one I can  print to from QPC2, the others have no DOS mode and 
simply ignore QPC2!). My QXLWINManager program comes in handy to 
rememeber and set up these long winded network path names, so it's 
quite practical to be running as many devices as you want and hot-swap 
the path names with WIN_DRIVE, DOS_DRIVE etc.
Yes that is what I thought you were doing.  That is using the network to 
access its resources as well as file names.

Worth a write up at sometime.  Just to alert a wider audience to this.
Do you do the 'hot-swap', i.e, whilst actively logged into the network, 
from within QPC2 or from Launchpad, or from the command line ?

My computing world seems to be a complex interaction of PC and QPC2. It 
used to be pretty clear cut - use the QPC2 for whatever I could and use 
Windows for everything else (usually scanning and email/internet) but 
what with Marcel's work on TCP/IP from QPC2 it's getting a little less 
clear cut than it used to be!
Yes, well that is the point ... it is a way into extended access and 
resources of the hardware.  As well as the software.

Now all I need to do is persuade either QPC2 or PC to answer the phone 
for me to filter out the whacky sales calls getting in the way of the 
real customers! Perhaps I could make up a stupid CD of prank sounds for 
QPC2's CD Player to play to the endless telephone salesmen while I 
leave them on hold!
Although at present QPC2 is running on top SMSQ/E which is on top of 
Windows, because of Directx, etc, and not in native mode.

If SMSQ/E or a further development of the concept was an OS for the 
hardware and software then it would be akin to a Linux set up. 
Interesting.

--
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QLib maintained

2005-01-13 Thread Roy wood
In message <[EMAIL PROTECTED]>, Malcolm Cadman 
<[EMAIL PROTECTED]> writes

Just to mention it again, it seems that Qlib should maintained, somehow.
If I recall it is from 1993 that it ceased to be developed.
I tried to get in touch with the authors some time ago but they are lost 
in the ether. I have a few copies of their programs that I bought some 
time ago but no-one buys them now. I did talk to Ian Stewart about 
getting to source code so I could get some work done on this but he was 
not the main programmer and did not have it. He said he was no longer in 
touch with the other author - whose name I forget. If anyone can contact 
them I would be happy to talk to them about the possibility of getting 
it supported..
--
Roy Wood
Q Branch. 20 Locks Hill, Portslade, Sussex.BN41 2LB
Tel: +44 (0) 1273 386030fax: +44 (0) 1273 430501
web : www.qbranch.demon.co.uk

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] BMP files etc

2005-01-13 Thread Rich Mellor
On Thu, 13 Jan 2005 18:18:49 +, Malcolm Cadman <[EMAIL PROTECTED]>  
wrote:

In message  
<[EMAIL PROTECTED]>,  
[EMAIL PROTECTED] writes

Dilwyn, with all the stuff that you are providing on your www site  
maybe
you should also consider an FTP repository. In that way all the files
available are readily accessible for download.

FTP came before HTTP and was designed for file access.  Although the
latter seems now to be more popular as users are more used to accessing
from a web site.

I've never set up an FTP site and would need help and advice to get it  
going, but it's something I'd consider. I've been very lucky with the  
Freeola UK6 site, it's reliable, has masses of free space and the only  
real restriction they place on you is that everything must be  
"visible", i.e. pages anyone can read or files anyone can download, you  
mustn't use it as a private file store. I guess they make their money  
from users dialling up.

Can you point me a source of information on getting and setting up an  
FTP site?
At present I haven't set up one either. Probably when Phoebus gets back  
on the list he will have the know how and information.

I have two net accounts, one with Demon and one with AOL.
The Demon account has everything, I just haven't investigated it for FTP.
The AOL account gives an easy to use access to storing files via FTP as  
a part of the package.

Perhaps Rich will know more about this too, as he may have a fuller AOL  
account than mine.
I don't think that AOL provides a free FTP upload and download area for  
non-members.
I don't use their service anymore except for internet access and some  
email - their servers (in common with most free space providers) were too  
unreliable and too slow.

I have plenty of space for FTP files on my servers but the problem is how  
do you provide a simple way of navigating to the right file and finding it?

You would have to look at the help file for your webspace provider in  
order to find out how to enable anonymous FTP - I can do this on my  
rwapservices.co.uk server through the control panel for the website.   
Anyone can then connect to my server using a username of  
[EMAIL PROTECTED] and their email address as the password.

It is not difficult to do on a paid web server.
--
Rich Mellor
RWAP Services
26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ
http://www.rwapservices.co.uk/
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QL filename length revisited

2005-01-13 Thread jms1

- Original Message -
From: "Wolfgang Lenerz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 12, 2005 6:03 AM
Subject: Re: [ql-users] QL filename length revisited


> I have a question here.
>
> Currently, the way directories are handled is by making a directory a
> somewhat special file (file type -1, IIRC).
>
> Apart from that, though,a  directory ia a simple file that can be
> accessed more or less like any file.
>
> Directories contain an "entry" per file referenced in that directory.
> Part of the entry is the filename of the file.
> However, and that is where the original designers made a design
> decision we all regret today, this filename is the ENTIRE name of the
> file, (minus the device name).
>
> Example: you have a file called "win1_subdir1_subdir2_subdir3_myfile"
>
> The filename as contained in the entry in subdir3_ for this file will be:
> "subdir1_subdir2_subdir3_myfile".
>
> As you can see, we are quickly getting to the 36 chars limit since that is
> the most space a filename can take in the directory file entry.
>
> Wouldn't the most simple way to get around the name length limitation
> be that each directory holds only the filename itself?
>
> Of course, each name on each directory level  would still be limited to
> 36 chars, but something like:
>
> win1_verylongsubdirname1_verylongsubdirname2_verylongsubdirnam
> e3_verylongsubdirname4_verylongsubdirname5_prettylongfilename
>
> would be possible.
> Perhaps the directory should be a new file type (-5 ot whatever) to
> show that this is a new type of directory.
>
> Legacy applications wouldn't work in this scheme. But, let's face it,
> whatever the scheme you are going to implement, they won't work
> (one, because the finale filemane will be too long anyway, two because
> they can't access new directories anyway).
>
>
> I'm just asking this question since I don't think I'd be competent enough
> to make these changes.
>
> Wolfgang
>
>
>
> ___
> QL-Users Mailing List
> http://www.q-v-d.demon.co.uk/smsqe.htm

Surely the trick is to check whether the directory is type 5. If so treat it
like a new directory and file naming. If not treat it like a type 255
directory.
Would you not get compatability then?

It should operate with an old QL. At present one just gets a long file name
listing all the directories and subdirectories as well as the final file
name.
Presumably the system would create a special file name prefix for each final
subdirectory. So on an ordinary QL the file name would be the special file
plus the final file name. If the directory files just showed their special
file name on an old QL and not the directory name them at least it would
make partial sense.

I assume that only people with hard drives would really be interested in
long directory trees and when they save to a floppy they would truncate the
directory tree.

PErhaps somewhere in this lot is the practical compromise

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] Program & Data specific directories or I'm home dear!!

2005-01-13 Thread jms1

- Original Message -
From: "P Witte" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 12, 2005 2:24 AM
Subject: Re: [ql-users]Long file & directory Trees


> jms1 writes:
>
> > I have not used the path rext but if it worked like path in MSDOS or
Unix
> > vatriants it would solve a lot of problems.
> >
> > A Path could be set up to cover all your program directories and then a
> > program will able to find its help, configurration or other files
because
> > it will be in the path.
> >
> > Data$ can be set to ones "home directory"
> > Prog$ can be set to start up program directory.
>
> I think people work to different paradigms. Paths are all well and good,
but
> wouldnt solve any problems for me unless the path string were half a mile
> long, which is impractical.
>
> > I have skipped the correspondence about long file names, but both
> > MSDOS and Unix use files as directories. These could contain the long
> > directory names and the actual directory name which is a single byte
> > allocated by the system (if 256 directories is enough!). The system
> > could automatically create the directory files and use them. Hence on
> > an old system the existing file names would work but a new system
> <>
>
> Currently Qdos directories are nothing else than a special kind of file,
ie
> just as you propose. Or do you mean that one should use an additional,
> secondary directory file with a different structure to store the "long"
> filenames?
>
> > Rather similar to the long file name change in Windows
>
> I once understood how Windoze got around the filename limitations of Msdos
> and thought it a clever idea (it was ugly, but it worked) but I can no
> longer
> remember. Does anyone here know?  And would it be possible for us to
> make use of the same method?
> <>
>
> Per
>
> ___
> QL-Users Mailing List
> http://www.q-v-d.demon.co.uk/smsqe.htm

The path works well for the two most used operating systems on small
computers namely Windows and Unix variants so it should work well on a QL!

George Gwilt tells me that in some of his programs you can pass a parameter
telling it which directory to use. So all we need is a convention that
adding the parameter -d directory will tell the program what directory to
use for data and - p directory will tell the program what directory the
program looks for config files and help files etc.

Then all currently maintained programs  and non copyright programs can be
updated with this facility.

I am sure would write an article explaining how he does it if anybody wants
this.

Or as Per Witte suggests make these configurable and then you can configure
the program to suite yourself.

Or even both adopt both solutions.

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QLib maintained

2005-01-13 Thread Tony Firshman
On  Thu, 13 Jan 2005 at 19:59:12, Roy wood wrote:
(ref: <[EMAIL PROTECTED]>)

>In message <[EMAIL PROTECTED]>, Malcolm Cadman
><[EMAIL PROTECTED]> writes
>
>>Just to mention it again, it seems that Qlib should maintained, somehow.
>>
>>If I recall it is from 1993 that it ceased to be developed.
>>
>I tried to get in touch with the authors some time ago but they are
>lost in the ether. I have a few copies of their programs that I bought
>some time ago but no-one buys them now. I did talk to Ian Stewart about
>getting to source code so I could get some work done on this but he was
>not the main programmer and did not have it. He said he was no longer
>in touch with the other author - whose name I forget. If anyone can
>contact them I would be happy to talk to them about the possibility of
>getting it supported..
Adrian Soundy
8 Newcroft Close
HILLINGDON
Middx
UB8 3RJ

.. but I expect he has moved.

BTW you said precisely the same thing (incl forgetting Adrian's name)
here on March 18th last (8-)#

Tony

-- 
 QBBS (QL fido BBS 2:252/67) +44(0)1442-828255
 tony@.co.uk  http://firshman.co.uk
   Voice: +44(0)1442-828254   Fax: +44(0)1442-828255
TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] I'm home, dear.

2005-01-13 Thread jms1
Sorry to sound so unnethusiatic but I cannot see that it is going to serve
any real purpose.

As I said in another email better to be able to cinfigure the program so it
has default locations for the program information and the data storage area.
Also let users specify these with parameters when they start up the program.

All problems to my miond are solved then.

- Original Message -
From: "Wolfgang Lenerz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 13, 2005 7:14 AM
Subject: Re: [ql-users] I'm home, dear.


> On 12 Jan 2005 at 23:46, Marcel Kilgus wrote:
>
> > > Your idea sounds excellent. Instead of my bicycle you and Wolfgang
have
> > > produced a Mercedes. I am in favour (as long as I dont have to produce
it ;)
> >
> > Damn, that was my precondition, too! ;-) But it does start to sound
> > like a worthwhile job.
>
> You will notice that (contrary to the long file names topic) I didn't ask
a
> question, but made a suggestion. This implies that I'm quite willing to
> do that stuff...
>
> I'm not promising anything quick, though.
>
> Can we more or less agree on the following:
>
> ---
> It will be set up as a "thing" (since I don't think we have found any
other
> satisfactory solution for compiled Basic).
> For each job, the thing should contain:
> the complete filename
> the dir whence it came from (home dir)
> the current dir which will initially be the home dir
>
> facilities should exist to
> set the complete filename. This will also set the home dir and current
> dir.
> get the filename, home dir and current dir.
> set the current dir (either directly or by ddup, ddown?)
> get the length of the file/dir names (this would only be of interest
>  if *somebody* actually gets around to implementing some form of
> long file names).
> set a default filename for a job with a certain name
>
> --
>
> Anything else?
>
> As usual, relatively few people have commented on this...
>
>
> Wolfgang
>
>
>
> ___
> QL-Users Mailing List
> http://www.q-v-d.demon.co.uk/smsqe.htm

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] Cold callers

2005-01-13 Thread jms1

- Original Message -
From: "Tony Firshman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 13, 2005 5:25 PM
Subject: [ql-users] Cold callers


> On  Thu, 13 Jan 2005 at 15:47:22,  wrote:
> (ref:
> <[EMAIL PROTECTED]>)
>
> 
> >Now all I need to do is persuade either QPC2 or PC to answer the phone
> >for me to filter out the whacky sales calls getting in the way of the
> >real customers! Perhaps I could make up a stupid CD of prank sounds for
> >QPC2's CD Player to play to the endless telephone salesmen while I
> >leave them on hold!
>
> I will not forget the guy on R4 You and Yours who said his approach was
> to sound very interested.  "Hold on a minute, I will get my wife.  I
> know it is just what she wants".  He then puts the phone on hold, and
> checks every once in a while.  Apparently his record was 45 minutes.
> The brilliant thing is that not only does the caller pay a fortune, but
> he cannot pester anyone else for that time.
> I wish I had the patience to do that.
>

Yes I do that something like that as well but I have I have never managed
more than 2 minutes. Perhaps I should invent an interested wife.

My other sport is to try and get the sales girls chatting and laughing. The
redder she is the more the rest of the room will be interested. Good
entertainment if you are not busy!

> I forget who it was now, but a friend or client has a long answer
> machine announcement, and they -never- actually answer that phone.
> They point out on tape that they do not want to hear from non-customers
> (ie prize announcements and the like).  They then filter from that and
> only give the -real- number to people they want to hear from.
>
> Sounds brilliant to me, but you do need at least one other number (plus
> maybe another for fax).
> >
> >(Before anyone says it, we tried TPS,
> TPS?
> > judging by the accents many of these calls are probably from foreign
> >call centres anyway...Path Name Length error...wonder if I could get
> >away with saying "Sorry I only speak Welsh" to them?).
> What language would you say that in (8-)#
>
> Tony
> --
>  QBBS (QL fido BBS 2:252/67) +44(0)1442-828255
>  tony@.co.uk  http://firshman.co.uk
>Voice: +44(0)1442-828254   Fax: +44(0)1442-828255
> TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
> ___
> QL-Users Mailing List
> http://www.q-v-d.demon.co.uk/smsqe.htm

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QLib maintained

2005-01-13 Thread Roy wood
In message <[EMAIL PROTECTED]>, Tony Firshman 
<[EMAIL PROTECTED]> writes
Adrian Soundy
8 Newcroft Close
HILLINGDON
Middx
UB8 3RJ
.. but I expect he has moved.
BTW you said precisely the same thing (incl forgetting Adrian's name)
here on March 18th last (8-)#
Correct. I did write but got no reply. I will try again. Ian doubted the 
sources still existed when we last spoke.
--
Roy Wood
Q Branch. 20 Locks Hill, Portslade, Sussex.BN41 2LB
Tel: +44 (0) 1273 386030fax: +44 (0) 1273 430501
web : www.qbranch.demon.co.uk

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QLib maintained

2005-01-13 Thread Jeremy Taffel
Roy wood wrote:
In message <[EMAIL PROTECTED]>, Tony Firshman 
<[EMAIL PROTECTED]> writes

Adrian Soundy
8 Newcroft Close
HILLINGDON
Middx
UB8 3RJ
.. but I expect he has moved.
BTW you said precisely the same thing (incl forgetting Adrian's name)
here on March 18th last (8-)#
Correct. I did write but got no reply. I will try again. Ian doubted 
the sources still existed when we last spoke.
There are 89 Soundys in the 2003 electoral register, but no Adrian.  
There are even some in Hillingdon  (relatives perhaps) but not Newcroft 
Close.  Lots of Andrew Soundys. Are you sure his first name is Adrian, 
because if so, it looks like he no longer lives in the UK

Jeremy



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.11 - Release Date: 12/1/05
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


[ql-users] FTP access

2005-01-13 Thread Malcolm Cadman
In message <[EMAIL PROTECTED]>, Rich Mellor 
<[EMAIL PROTECTED]> writes
On Thu, 13 Jan 2005 18:18:49 +, Malcolm Cadman 
<[EMAIL PROTECTED]>  wrote:

In message 
<[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] writes

Can you point me a source of information on getting and setting up 
an FTP site?
At present I haven't set up one either. Probably when Phoebus gets 
back   on the list he will have the know how and information.

I have two net accounts, one with Demon and one with AOL.
The Demon account has everything, I just haven't investigated it for FTP.
The AOL account gives an easy to use access to storing files via FTP 
as   a part of the package.

Perhaps Rich will know more about this too, as he may have a fuller 
AOL   account than mine.
I don't think that AOL provides a free FTP upload and download area for 
non-members.
Ah yes, that is the catch.  It is a 'members' only service. Although 
'non-members' ought to be able to download only?  Through anonymous FTP.

I have just been using it again for the first time in a long time, and 
there is 20Mb of space per user name. With up to 7 user names.  More 
space than I had realised.  The user interface has also been improved 
with everything being done via icons.

I don't use their service anymore except for internet access and some 
email - their servers (in common with most free space providers) were 
too unreliable and too slow.
Odd. I use for web browse searches, and all my downloads as it easy and 
quick.

I have plenty of space for FTP files on my servers but the problem is 
how do you provide a simple way of navigating to the right file and 
finding it?
Well it just set up like a hard drive, directories with the name of the 
contents.

You could have a 'QWord Update' directory, for example, and users just 
navigate to it, and then download.

You would have to look at the help file for your webspace provider in 
order to find out how to enable anonymous FTP - I can do this on my 
rwapservices.co.uk server through the control panel for the website. 
Anyone can then connect to my server using a username of 
[EMAIL PROTECTED] and their email address as the password.

It is not difficult to do on a paid web server.
Yes it is convenient.
--
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [ql-users] QLib maintained

2005-01-13 Thread Malcolm Cadman
In message <[EMAIL PROTECTED]>, Roy wood 
<[EMAIL PROTECTED]> writes

In message <[EMAIL PROTECTED]>, Malcolm Cadman 
<[EMAIL PROTECTED]> writes

Just to mention it again, it seems that Qlib should maintained, somehow.
If I recall it is from 1993 that it ceased to be developed.
I tried to get in touch with the authors some time ago but they are 
lost in the ether. I have a few copies of their programs that I bought 
some time ago but no-one buys them now. I did talk to Ian Stewart about 
getting to source code so I could get some work done on this but he was 
not the main programmer and did not have it. He said he was no longer 
in touch with the other author - whose name I forget. If anyone can 
contact them I would be happy to talk to them about the possibility of 
getting it supported..
Yes, getting the source code is important, and any remaining copyright 
issues.

I have drawn a blank with a similar quest in trying to contact David 
Batty of Sector Software for the Perfection software.

Following this Dave Gilham is now looking at making the enhanced full 
screen version, that was discussed at the end of 2004, available with a 
limited license condition.

--
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


[ql-users] Accessing FTP

2005-01-13 Thread Malcolm Cadman
In message <[EMAIL PROTECTED]>, Rich Mellor 
<[EMAIL PROTECTED]> writes
On Thu, 13 Jan 2005 18:18:49 +, Malcolm Cadman 
<[EMAIL PROTECTED]>  wrote:

In message 
<[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] writes

Dilwyn, with all the stuff that you are providing on your www site 
maybe
you should also consider an FTP repository. In that way all the files
available are readily accessible for download.

FTP came before HTTP and was designed for file access.  Although the
latter seems now to be more popular as users are more used to accessing
from a web site.

I've never set up an FTP site and would need help and advice to get 
it going, but it's something I'd consider. I've been very lucky with 
Freeola UK6 site, it's reliable, has masses of free space and the 
only real restriction they place on you is that everything must be 
"visible", i.e. pages anyone can read or files anyone can download, 
you mustn't use it as a private file store. I guess they make their 
money from users dialling up.

Can you point me a source of information on getting and setting up 
an FTP site?
Can you try this from your web browser ?
I have tested it from Demon with Internet Explorer, and it works.
ftp://members.aol.com/mcadman/
It should bring up Windows Explorer and show some folders and files.
One of the folders is set to 'Private' i.e, only available to myself as 
a member, the others should be open to anyone, and can be looked or 
downloaded where appropriate.

Just navigate it like any other device.
--
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm