On 11 Jan 2005 at 6:49, Wolfgang Lenerz wrote:
(...)
> I wrote some extensions for this quite some time ago.
> You might want to check my download site and get the bmp converter
> prog for this!
>
> Alternatively, use the enclosed keywords.
Sorry, I sent that before I noticed that the problem h
On Mon, 10 Jan 2005 at 18:21:59, James Hunkins wrote:
(ref: <[EMAIL PROTECTED]>)
>
>Now, this raises the question, why do we not have a native QL program
>that can convert one of the major image formats to a _scr image
>directly? I found tons of stuff that converts between formats plus
>from _S
There has been some talk on this list about some form of
"currrent directory" or "home directory" for programs that
are being executed.
As far as I understand it, the purpose of such a directory is to
give the program the name of the directory from which the file was
executed, so that, for exampl
> Lynx is GPL license and you should include the source.
> Perhaps the answer is to unzip on a linux box, change the directory names to
> shorter ones and zip it up again.
Probably breaks terms of licence in much the same way and certainly fouls up
replacement should Jonathan update it.
What I've
Wolfgang Lenerz wrote:
> There has been some talk on this list about some form of
> "currrent directory" or "home directory" for programs that
> are being executed.
>
> As far as I understand it, the purpose of such a directory is to
> give the program the name of the directory from which the file
P Witte wrote:
Perhaps we should have another bash at finding a solution to our
debilitating filename length problem?
Let battle commence!
Per
What about QVFS QDOS Virtual File System by Hans-Peter Reckenwald?
François Van Emelen
___
QL-Users Mailing Li
> The answer is to create two zip files, one with the runtime version and
> one with the sources etc - we know the second one will not unzip on the QL
> properly. Then zip these two zip files together - so there is ONE
> download.
>
> The user can unzip on the PC and then access the runtime
Dilwyn Jones writes:
<>
> We've down this road many times before, unless Marcel has new ideas to
> offer I don't really see the point of raising this again. Just because
> JRH managed to exceed 36 characters in his zip files!
Not quite. Ive always lobbied for an advanced new file system. Im now
p
Marcel Kilgus writes:
<>
Im assuming that you were answering two different mails here. Forget the QPC
'hole' that got me going and lets look at path depth for SMSQ/E in general:
> Unfortunately directories have to be read "raw", meaning that the
> format is limited to 36 characters. If one were
Kjartan Geble Olsen writes:
Norsk?
> > But I can already hear the whining "but I can't adapt my application
> > to use the new traps as then it wouldn't be QDOS compatible anymore",
> > so I probably just don't bother. Not trying to discourage anybody
> > else, of course, it's just my view of thi
On Tue, 11 Jan 2005 11:42:37 -, P Witte <[EMAIL PROTECTED]>
wrote:
<>
The recent questionnair should be able to answer the question: What
percentage of QLers use both Qdos AND hard disks [HDD] (a small
percentage I
would think) Minerva and emulator users can upgrade the OS. Hardware Qdos
u
François Van Emelen writes:
> Perhaps we should have another bash at finding a solution to our
> debilitating filename length problem?
> Let battle commence!
> Per
What about QVFS QDOS Virtual File System by Hans-Peter Reckenwald?
François Van Emelen
I did mention this (option 2) I tried it a l
> >Now, this raises the question, why do we not have a native QL program
> >that can convert one of the major image formats to a _scr image
> >directly? I found tons of stuff that converts between formats plus
> >from _SCR to others. The only one I found reference to was called
> >BMP2SCR but I c
> > Perhaps we should have another bash at finding a solution to our
> > debilitating filename length problem?
>
> > Let battle commence!
> > Per
>
> What about QVFS QDOS Virtual File System by Hans-Peter Reckenwald?
> François Van Emelen
>
> I did mention this (option 2) I tried it a long time
> > >Now, this raises the question, why do we not have a native QL program
> > >that can convert one of the major image formats to a _scr image
> > >directly? I found tons of stuff that converts between formats plus
> > >from _SCR to others. The only one I found reference to was called
> > >BMP2S
On 11 Jan 2005 at 10:53, John Hall wrote:
(...)
> Conceptually, I'm not keen on this centralised approach - it seems
> rather too Windows-like!
>
> Since it's an item of job-specific data, couldn't it be associated
> with a job-specific data area or structure (e.g. put on the stack
> prior to act
Quite agree. I too have recently been driven nuts with the limitations.
A new set of
traps to an advanced directory system sounds good. Perhaps with a new
'CD' navigation
command. I suppose the old traps could be rewritten such that older
software has
access to the new system to a path length of
On 11 Jan 2005 at 16:24, Malcolm Lear wrote:
(...)
> Does anyone
> know the history
> of the 36 character limit. Was it a file name length limit set before
> directories came about?
Yes. At first the Ql didn't have directories at all. They came, unless I'm
mistaken with TK II and disk interfac
Wolfgang Lenerz wrote:
>> Apart from anything else, this would maintain the "self-cleaning"
>> property of the operating system...
> True.
> However, how do you get at that from basic, espacially compiled basic?
Without having any personal view on the issue yet, isn't it basically
the same issue a
On 11 Jan 2005 at 17:44, Marcel Kilgus wrote:
(...)
> Without having any personal view on the issue yet, isn't it basically
> the same issue as with CMD$? Does CMD$ work in compiled basic?
Yes and no. (That's a true lawyes's anwer for you)
No problem for Sbasic itself, of course.
However, while CM
Wolfgang Lenerz wrote:
> Yes and no. (That's a true lawyes's anwer for you)
> No problem for Sbasic itself, of course.
> However, while CMD$ works in Qlib, this is only because Qlib has it's own
> CMD$ command. There is no way to have a similar home$ command in Qlib.
Ah, very well. Anyway, if one
Wolfgang Lenerz wrote:
--->> Finally, progs executed from memory (executable things) would
> probably not have a home directory, unless a facility is set up
> whereby a default home dir is set up for programs with a certain
> name.
Default could also be DATAD$ or whatever.
> - Via QPAC2. This wou
On 11 Jan 2005 at 18:19, Marcel Kilgus wrote:
> Default could also be DATAD$ or whatever.
that would defeat the wholme exercice. Why not have the user set the default?
(...)
>
> Hm, the meaning of a Trap #3 depends on a specific device you've
> opened, not a good choice IMO. But if you do use
- Original Message -
From: "Dilwyn Jones" <[EMAIL PROTECTED]>
To: "QL Users List" <[EMAIL PROTECTED]>
Sent: Monday, January 10, 2005 12:21 AM
Subject: [ql-users] Lynx and QPC2
>
> To get a copy, goto www.dilwyn.uk6.net/internet/index.html or browse
> there from my home page of course. Th
- Original Message -
From: "P Witte" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 10, 2005 2:11 AM
Subject: Re: [ql-users] Lynx 282
> Dilwyn Jones writes:
>
> > I honestly don't believe this is useable on QPC2.
>
> Poor old Dilwyn. My commiserations (in advance) for
In message <[EMAIL PROTECTED]>, James
Hunkins <[EMAIL PROTECTED]> writes
Any other suggestions out there?
It turns out that the software Phoebus is working on runs on Windows
and is tied to Microsoft's .net stuff which I am not setup with and
can't afford to install this close to QDT release.
Y
In message <[EMAIL PROTECTED]>, James
Hunkins <[EMAIL PROTECTED]> writes
I converted the image, as described in a separate thread, to a PNG
format file, used Marcel's windows program to convert that to a QL _SPR
image, and then in SBASIC with the build in commands displayed it on
the screen (
In message <[EMAIL PROTECTED]>, Dilwyn Jones
<[EMAIL PROTECTED]> writes
In an indirect way, by defining the pseudo devices like DEV you can
work around this to some extent in some circumstances if you are
desperate. Setting the base devices for DOS to have longer Windows path
names lets me ac
Or a completely different proposal:
Lets take the standard job as the starting point. Dealing with QLiberated or
Turboed jobs need some special treatment.
When a job is first started it has a code area and a data area. If there are
open channels or a command line the Basic keywords EX (and family
Isn't the new mac mini everything you want in a replacement QL?
What would it take for us to put together something as tidy as this?
http://www.apple.com/macmini/design.html
Dave
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
- Original Message -
From: "Tony Firshman"
To: <[EMAIL PROTECTED]>
Sent: Monday, January 10, 2005 9:08 PM
Subject: Re: [ql-users] QL shows (was QWord payment)
I meant Bill let -us- know when his favourite m/c shows are - preferably
late next year or 2006.
I appreciate that, but we are no
- Original Message -
From: "John Gilpin"
To: <[EMAIL PROTECTED]>
Sent: Monday, January 10, 2005 11:00 PM
Subject: Re: [ql-users] good superbasic book?
In my copy there is a preface to the second edition dated 19th July 1989
and
at the foot of that page there is a Copyright Notice
"As o
On Tue, 11 Jan 2005 22:00:37 -, P Witte <[EMAIL PROTECTED]>
wrote:
Or a completely different proposal:
Lets take the standard job as the starting point. Dealing with
QLiberated or
Turboed jobs need some special treatment.
When a job is first started it has a code area and a data area. If
Rich Mellor wrote:
> I prefer this type of approach as it would ensure that the home
> directory (or whatever) would be removed together with the job.
If the job "uses" the thing, the thing is informed when the job dies.
Even if not, one could allocate the necessary memory on behalf of the
job and
Wolfgang Lenerz wrote:
>> Default could also be DATAD$ or whatever.
> that would defeat the wholme exercice.
Why that? It's just a fallback solution if otherwise no other
directory can be provided (none set).
>> Hm, the meaning of a Trap #3 depends on a specific device you've
>> opened, not a goo
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
I've updated the Graphics page on my software download site to include
the BMP and QL high colour screen conversion and other graphical
utilities as I mentioned earlier today. The upload includes a copy of
the article from Vol 8 Issue 3 of QL Today and the SBASIC listings
showing how to convert
In message <[EMAIL PROTECTED]>, Rich Mellor
<[EMAIL PROTECTED]> writes
On Tue, 11 Jan 2005 11:42:37 -, P Witte <[EMAIL PROTECTED]>
wrote:
<>
The recent questionnair should be able to answer the question: What
percentage of QLers use both Qdos AND hard disks [HDD] (a small
percentage I
would
In message <[EMAIL PROTECTED]>, Marcel Kilgus
<[EMAIL PROTECTED]> writes
Why? Personally the file name limit actually doesn't bother me too
much. More other things like the missing "current directory"
functionality.
Just a thought but id there no way to make the current character length
limit the
What about unzipping to a windows machine, renaming the directories
so that
they do notr cause problems for qdos and then rezip them. Surely
this is
cleaner!
In addition to renaming the directories you'd have to go through
patching files. Some of the html files for example have hard coded
refe
Have you got the improved Norman Dunbar software - which is called
'Snatch-IT' I believe ? ... although I could be wrong with the name.
It was originally developed for QDOS, but Norman modified it to work
under QPC so that higher pixel count images could be 'snatched' from
the screen.
You cou
In an indirect way, by defining the pseudo devices like DEV you can
work around this to some extent in some circumstances if you are
desperate. Setting the base devices for DOS to have longer Windows
path names lets me access files in long and deep subdirectories in
Windows from QPC2. When you
2) The bigger problem and one which is harder to address...
How do you decide what is the home directory of a file called
win1_basic_exts_turbo_config_exe
I guess the code which sets up the job would have to look at each of
the levels before the underscore to see if they were set up as a
direc
Wolfgang Lenerz wrote:
There has been some talk on this list about some form of
"currrent directory" or "home directory" for programs that
are being executed.
As far as I understand it, the purpose of such a directory is to
give the program the name of the directory from which the file was
executed
Rich Mellor writes:
<>
> > It would not be difficult to stack the home directory on top
> > of that again thus:
> >
> > Home directory
> > Command string
> > Channel ID
> > Channel ID
> >
> > number of channel IDs
> > Data area
> >
> > At present (a6,a5) point to the top of the data area. Thi
Marcel Kilgus writes:
<>
> If the job "uses" the thing, the thing is informed when the job dies.
> Even if not, one could allocate the necessary memory on behalf of the
> job and therefore it would get freed along with the job.
>
> So far I think I'd prefer that over any stack hack, but I haven't
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 b
On 11 Jan 2005 at 22:00, P Witte wrote:
> Or a completely different proposal:
(putting the home dir after the command string)
> (...)
> QLib compiled programs pose a challenge as we dont have access to the
> compiled job's initialisation code to access that information. However,
> there are othe
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
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
On 12 Jan 2005 at 0:39, Marcel Kilgus wrote:
> Wolfgang Lenerz wrote:
> >> Default could also be DATAD$ or whatever.
> > that would defeat the wholme exercice.
>
> Why that? It's just a fallback solution if otherwise no other
> directory can be provided (none set).
Well, it already exists...
Wou
On 12 Jan 2005 at 2:20, P Witte wrote:
> Whatever the low-down implementation, ideally the workings of the HD/CD
> should be as consistent as possible accross m/c programs, interpreted Sbasic
> or compiled Sbasic.
Anything that wouldn't be available to compiled Sbasic wouldn't make
much sense!
On Jan 11, 2005, at 7:32 AM, <[EMAIL PROTECTED]> wrote:
Now, this raises the question, why do we not have a native QL
program
that can convert one of the major image formats to a _scr image
directly? I found tons of stuff that converts between formats plus
from _SCR to others. The only one I fou
I am glad you did anyway as your way is a bit more straight forward.
Yours allows for a more direct conversion if I recall.
Can you give a breakdown again of the different
Cheers,
jim
On Jan 11, 2005, at 12:11 AM, Wolfgang Lenerz wrote:
On 11 Jan 2005 at 6:49, Wolfgang Lenerz wrote:
(...)
I wrot
Yes, it would be great.
But, believe me, you do NOT want to know what it takes to design
something like this. And it would also cost as much as probably 2-3x
as much to build even if you could get the circuit boards cheep. Apple
does squeeze its vendors for pricing and its engineers for space
Oops, sent it before this was done - sorry.
Meant to say...
On Jan 11, 2005, at 10:35 PM, James Hunkins wrote:
I am glad you did anyway as your way is a bit more straight forward.
Yours allows for a more direct conversion if I recall.
Can you give a breakdown again of the different keywords (att
Hi Dilwyn,
I don't think that I see the changes. Am I blind or did they not
actually get uploaded yet?
Thanks,
jim
On Jan 11, 2005, at 4:08 PM, Dilwyn Jones wrote:
I've updated the Graphics page on my software download site to include
the BMP and QL high colour screen conversion and other graph
57 matches
Mail list logo
