Re: [ql-users] SMSQE v3.10 and beyond
On 1 Sep 2006, at 16:39, Wolfgang Lenerz wrote: From SMSQE v3.10 I started having difficulty with the Q40, although the Q60 was OK. The Q40 refused to recognise the hard disk and so stopped early on in the BOOT after LRESPRing SMSQE. Typing RESET corrected this. Unfortunately v3.12 crashes the Q40 altogether when it is LRESPRd. Has anyone else found this? Also, although the Q60 appears to work with v3.12, in particular the HISTORY is good, screen display is slower. Indeed in some cases I have to wait up to four seconds before a response. Is this just me? The cache handling for the Qx0 changed quite a bit during these versions. The caches are now set up to be off by default, leaving the Qx0 in the slowest - but safest state. Try using writethrough etc in your boot file. I don't have the problems you descibe, but then I have a Q60 - there *shouldn't* be any difference! SMSQE v3.10 on the Q40 requires me to type RESET as i have said. This, for some reason, allows the hard disk to be recognised, As you say, operation is slow and I alter that by typing COPYBACK. However, SMSQE v3.12 on the Q40 gets nowhere near a BOOT. If I LRESPR v3.12, the machine immediately stops. So, at a very early stage, something is wrong. Has anyone successfully used 3.12 on a Q40? George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] bug in qlib_h C68 support file
Guys, I think that I found a bug in the qlib_h include file used by C68. Here are the details: In the 'qdirect' structure, the member 'd_name' is defined as: char d_name[36]; This works as long as the directory/file name is 35 or fewer characters and holds a properly terminated C string (terminates with a '0'). However, if the total name length is actually 36 characters, then there is no termination. As far as I can tell the structure does properly hold everything and isn't corrupt, just no termination in that one case. This might explain why in a few problems with long file names, I see handling problems but not in others (compiled in C68 versus assembly or compiled SBASIC for example?). If I am correct this structure should define it as: char d_name[37]; to allow room for the termination character of a C string. Jim ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] bug in qlib_h C68 support file
James Hunkins wrote:
I think that I found a bug in the qlib_h include file used by C68.
Here are the details:
In the 'qdirect' structure, the member 'd_name' is defined as:
char d_name[36];
Your misconception is that d_name holds a null terminated string,
which it doesn't. The length of the string is in d_szname. If you need
a C string, you have to copy it, for example like this:
#define MAX_FILENAME 38 // 38 because 37 is just so uneven ;-)
{
char buffer[MAX_FILENAME];
char *name;
[...]
name = qlstr_to_c(buffer, (struct QLSTR *)dir.d_szname);
Note that name always points to buffer afterwards and thus is only
valid as long as buffer is in scope. If you need it for longer, malloc
the space for buffer instead of allocating it on the stack.
If I am correct this structure should define it as:
char d_name[37];
to allow room for the termination character of a C string.
That'd be pretty fatal, not only because of possible alignment
problems but because qdirect does not define an abstract data
structure you can arbitrarily change, it just provides a mapping onto
the data structure QDOS uses (which is also the reason the string is
not null terminated) and thus has to mach byte by byte.
By the way, I suggest to write new code in a way so that it might one
day easily be changed to handle more than 36 characters. Thus the
MAX_FILENAME define in the example.
Marcel
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] bug in qlib_h C68 support file
James, The header is correct - it defines a memory structure in QDOS, not a structure designed for use with C. As such the definition is fixed and cannot be changed. You will find that under QDOS all strings are preceded by a 2-byte field that defines the length of the following string, and strings are not zero-terminated. When programming in C one should always therefore take account of this, and make sure that you use the length limiting variants of copies and moves as you cannot assume a zero termination to such strings. It can be advantageous to look at the .hdr versions of the header files supplied on one of the source disks.These include comments which can make the files much easier to peruse. You can also rename them and put them in place of the supplied .h files which have been processed to remove all comments and formatting to reduce their size for those using floppy based systems. Those using hard disk based systems are better off using the commented versions Dave . - Original Message - From: James Hunkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 04, 2006 3:18 PM Subject: [ql-users] bug in qlib_h C68 support file Guys, I think that I found a bug in the qlib_h include file used by C68. Here are the details: In the 'qdirect' structure, the member 'd_name' is defined as: char d_name[36]; This works as long as the directory/file name is 35 or fewer characters and holds a properly terminated C string (terminates with a '0'). However, if the total name length is actually 36 characters, then there is no termination. As far as I can tell the structure does properly hold everything and isn't corrupt, just no termination in that one case. This might explain why in a few problems with long file names, I see handling problems but not in others (compiled in C68 versus assembly or compiled SBASIC for example?). If I am correct this structure should define it as: char d_name[37]; to allow room for the termination character of a C string. Jim ___ 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] bug in qlib_h C68 support file
On Mon, 04 Sep 2006 15:18:59 +0100, James Hunkins [EMAIL PROTECTED] wrote: Guys, I think that I found a bug in the qlib_h include file used by C68. Here are the details: In the 'qdirect' structure, the member 'd_name' is defined as: char d_name[36]; This works as long as the directory/file name is 35 or fewer characters and holds a properly terminated C string (terminates with a '0'). However, if the total name length is actually 36 characters, then there is no termination. As far as I can tell the structure does properly hold everything and isn't corrupt, just no termination in that one case. This might explain why in a few problems with long file names, I see handling problems but not in others (compiled in C68 versus assembly or compiled SBASIC for example?). If I am correct this structure should define it as: char d_name[37]; to allow room for the termination character of a C string. Jim, Yes you are of course correct - however, just to be on the safe side, it should really be set to char d_name[42] this allows the device name (5 chars) as well as the terminating character. Now - can anyone tell me why if you use FSERVE, the network name including n1_ (or whatever) to access a remote file is restricted to 39 characters? As a result of this, the full 41 characters should never be used. -- Rich Mellor RWAP Services URL:http://www.rwapsoftware.co.uk URL:http://www.rwapadventures.com URL:http://www.rwapservices.co.uk URL:http://www.internetbusinessangels.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] bug in qlib_h C68 support file
On Mon, 04 Sep 2006 15:49:18 +0100, Marcel Kilgus [EMAIL PROTECTED] wrote: James Hunkins wrote: I think that I found a bug in the qlib_h include file used by C68. Here are the details: In the 'qdirect' structure, the member 'd_name' is defined as: char d_name[36]; Your misconception is that d_name holds a null terminated string, which it doesn't. The length of the string is in d_szname. If you need a C string, you have to copy it, for example like this: Oops sorry - I didn't look at the library - if d_name doesn't hold a null terminated string, then that is of course correct. However, ideally the minimum surely has to be 36+5?? (rounded up to 42) or does the library have a distinct device name string also?? -- Rich Mellor RWAP Services URL:http://www.rwapsoftware.co.uk URL:http://www.rwapadventures.com URL:http://www.rwapservices.co.uk URL:http://www.internetbusinessangels.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] bug in qlib_h C68 support file
Rich Mellor wrote: However, ideally the minimum surely has to be 36+5?? (rounded up to 42) or does the library have a distinct device name string also?? No, the device name is not part of the directory/file name. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] bug in qlib_h C68 support file
Hi Guys,
Three things were fooling me:
1) I was calling this using a C function so I 'assumed' that it was
converting to C strings
2) when I grab the string, if under 36 characters, it always seems to
have a 0 termination at the end
[ assembly might be right filling the string with this ]
3) I do not see the first values at the start of the string for length
- I can handle this as a C string and have no garbage at the
beginning and it terminates properly if 36 chars
The way I am using this is:
DIR_LIST_t *tFileList;
GetFileType(tFileList-dl_dir.d_name); /* calling
function */
short GetFileType(char *FileName)
{
printf(FileName: [%s]\n, FileName); /* this prints
out the
filename just fine if 36 chars */
}
Unless I am missing something, it seems that the C call (haven't had
time to dig up the source file yet) does at last a partial conversion
from the QDOS structure. Whether it on purpose adds the termination
for items 36 chars or not, don't know.
With that said, going to take a break outside now that the rain has
'stopped' for a bit (3 day weekend, last of summer = rain).
Cheers,
jim
On Sep 4, 2006, at 10:51 AM, Dave Walker wrote:
James,
The header is correct - it defines a memory structure in QDOS, not a
structure designed for use with C. As such the definition is
fixed and
cannot be changed. You will find that under QDOS all strings are
preceded
by a 2-byte field that defines the length of the following string, and
strings are not zero-terminated. When programming in C one should
always
therefore take account of this, and make sure that you use the length
limiting variants of copies and moves as you cannot assume a zero
termination to such strings.
It can be advantageous to look at the .hdr versions of the header
files
supplied on one of the source disks.These include comments
which can
make the files much easier to peruse. You can also rename them
and put
them in place of the supplied .h files which have been processed to
remove
all comments and formatting to reduce their size for those using
floppy
based systems. Those using hard disk based systems are better off
using the
commented versions
Dave
.
- Original Message -
From: James Hunkins [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 04, 2006 3:18 PM
Subject: [ql-users] bug in qlib_h C68 support file
Guys,
I think that I found a bug in the qlib_h include file used by C68.
Here are the details:
In the 'qdirect' structure, the member 'd_name' is defined as:
char d_name[36];
This works as long as the directory/file name is 35 or fewer
characters and holds a properly terminated C string (terminates with
a '0'). However, if the total name length is actually 36 characters,
then there is no termination. As far as I can tell the structure
does properly hold everything and isn't corrupt, just no termination
in that one case.
This might explain why in a few problems with long file names, I see
handling problems but not in others (compiled in C68 versus assembly
or compiled SBASIC for example?).
If I am correct this structure should define it as:
char d_name[37];
to allow room for the termination character of a C string.
Jim
___
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
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] MCALLT
Does anyone have any experience of using MCALLT in Easyptr? I'm looking for a few examples of making use of the timeout and events (general tinkering), and perhaps for adding help 'bubbles' to my programs. 2 of my programs (Decimal Invaders and Status) use the timeout facility to allow something to be counted or printed if nothing happens within a short time, but that's about as far as I ever got with it. The Easyptr manual is pretty scant on the subject, basically describing it as an MCALL with a couple of extra parameters in Easyptr's IMPORTANT_TXT file. It doesn't really give any examples showing to properly use it. As far as I know, item=MCALLT(#ch%\event%,time%) times out after time% frames (50=1 second), and the event% parameter seems to be: bits0-7 set - allow termination of call by events listed in pt1/42 (Do, ESC, F1 etc) as long as \ is used after #ch% bits 8-15 (although suggested to be upper nybble bits 12-15) allow smsq/e job events??? Since SMSQ/E allows 8 events but only 4 bits are available, if I'm correct it must be a hex value 0 to 7 in those 4 bits??? A timeout return seems to be indicated by item=-1280 (not sure of the significance of that number) and event% being returned unchanged in value if no 'event' occurred. Can anyone give a better explanation, or provide a few examples or documentation on the subject? Apart from the bubble help perhaps I don't really have any particular use in mind, just learnign more about it. -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.7/436 - Release Date: 01/09/2006 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] bug in qlib_h C68 support file
James,
QDOS strings in C68 are normally represented by 2 fields as follows:
unsigned short d_szname; /* size of name */
char d_name[36]; /* name area */
the first being a short with the length, and the next being a char field
with the contents. In your case it is actually working by 'luck' in that
QDOS tends to zero fill the unused space.This is however not guaranteed
behaviour, and as you noted your code will fail if the name is the maximum
allowed. If you wanted to write bullet-proof C code you would use the
preceeding length field (d_szname) to tell you how much is valid in the
d_name field. Also the QDOS format allows for 0 characters to be part of
the name, and again with your code this would fail as it would assume the 0
byte was the name terminator rather than part of the name itself.
Dave
- Original Message -
From: James Hunkins [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 04, 2006 5:34 PM
Subject: Re: [ql-users] bug in qlib_h C68 support file
Hi Guys,
Three things were fooling me:
1) I was calling this using a C function so I 'assumed' that it was
converting to C strings
2) when I grab the string, if under 36 characters, it always seems to
have a 0 termination at the end
[ assembly might be right filling the string with this ]
3) I do not see the first values at the start of the string for length
- I can handle this as a C string and have no garbage at the
beginning and it terminates properly if 36 chars
The way I am using this is:
DIR_LIST_t *tFileList;
GetFileType(tFileList-dl_dir.d_name); /* calling function */
short GetFileType(char *FileName)
{
printf(FileName: [%s]\n, FileName); /* this prints out the
filename just fine if 36 chars */
}
Unless I am missing something, it seems that the C call (haven't had
time to dig up the source file yet) does at last a partial conversion
from the QDOS structure. Whether it on purpose adds the termination
for items 36 chars or not, don't know.
With that said, going to take a break outside now that the rain has
'stopped' for a bit (3 day weekend, last of summer = rain).
Cheers,
jim
On Sep 4, 2006, at 10:51 AM, Dave Walker wrote:
James,
The header is correct - it defines a memory structure in QDOS, not a
structure designed for use with C. As such the definition is
fixed and
cannot be changed. You will find that under QDOS all strings are
preceded
by a 2-byte field that defines the length of the following string, and
strings are not zero-terminated. When programming in C one should
always
therefore take account of this, and make sure that you use the length
limiting variants of copies and moves as you cannot assume a zero
termination to such strings.
It can be advantageous to look at the .hdr versions of the header
files
supplied on one of the source disks.These include comments
which can
make the files much easier to peruse. You can also rename them
and put
them in place of the supplied .h files which have been processed to
remove
all comments and formatting to reduce their size for those using
floppy
based systems. Those using hard disk based systems are better off
using the
commented versions
Dave
.
- Original Message -
From: James Hunkins [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 04, 2006 3:18 PM
Subject: [ql-users] bug in qlib_h C68 support file
Guys,
I think that I found a bug in the qlib_h include file used by C68.
Here are the details:
In the 'qdirect' structure, the member 'd_name' is defined as:
char d_name[36];
This works as long as the directory/file name is 35 or fewer
characters and holds a properly terminated C string (terminates with
a '0'). However, if the total name length is actually 36 characters,
then there is no termination. As far as I can tell the structure
does properly hold everything and isn't corrupt, just no termination
in that one case.
This might explain why in a few problems with long file names, I see
handling problems but not in others (compiled in C68 versus assembly
or compiled SBASIC for example?).
If I am correct this structure should define it as:
char d_name[37];
to allow room for the termination character of a C string.
Jim
___
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
___
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] bug in qlib_h C68 support file
That was the piece that I was missing - thanks.
My code is corrected to translate the string first before passing it.
Thanks for the quick responses everyone!
jim
On 4-Sep-06, at 1:44 PM, Dave Walker wrote:
James,
QDOS strings in C68 are normally represented by 2 fields as follows:
unsigned short d_szname; /* size of name */
char d_name[36]; /* name area */
the first being a short with the length, and the next being a char field
with the contents. In your case it is actually working by 'luck' in
that
QDOS tends to zero fill the unused space.This is however not
guaranteed
behaviour, and as you noted your code will fail if the name is the
maximum
allowed. If you wanted to write bullet-proof C code you would use the
preceeding length field (d_szname) to tell you how much is valid in the
d_name field. Also the QDOS format allows for 0 characters to be
part of
the name, and again with your code this would fail as it would assume
the 0
byte was the name terminator rather than part of the name itself.
Dave
- Original Message -
From: James Hunkins [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 04, 2006 5:34 PM
Subject: Re: [ql-users] bug in qlib_h C68 support file
Hi Guys,
Three things were fooling me:
1) I was calling this using a C function so I 'assumed' that it was
converting to C strings
2) when I grab the string, if under 36 characters, it always seems to
have a 0 termination at the end
[ assembly might be right filling the string with this ]
3) I do not see the first values at the start of the string for length
- I can handle this as a C string and have no garbage at the
beginning and it terminates properly if 36 chars
The way I am using this is:
DIR_LIST_t *tFileList;
GetFileType(tFileList-dl_dir.d_name); /* calling function */
short GetFileType(char *FileName)
{
printf(FileName: [%s]\n, FileName); /* this prints out the
filename just fine if 36 chars */
}
Unless I am missing something, it seems that the C call (haven't had
time to dig up the source file yet) does at last a partial conversion
from the QDOS structure. Whether it on purpose adds the termination
for items 36 chars or not, don't know.
With that said, going to take a break outside now that the rain has
'stopped' for a bit (3 day weekend, last of summer = rain).
Cheers,
jim
On Sep 4, 2006, at 10:51 AM, Dave Walker wrote:
James,
The header is correct - it defines a memory structure in QDOS, not a
structure designed for use with C. As such the definition is
fixed and
cannot be changed. You will find that under QDOS all strings are
preceded
by a 2-byte field that defines the length of the following string,
and
strings are not zero-terminated. When programming in C one should
always
therefore take account of this, and make sure that you use the length
limiting variants of copies and moves as you cannot assume a zero
termination to such strings.
It can be advantageous to look at the .hdr versions of the header
files
supplied on one of the source disks.These include comments
which can
make the files much easier to peruse. You can also rename them
and put
them in place of the supplied .h files which have been processed to
remove
all comments and formatting to reduce their size for those using
floppy
based systems. Those using hard disk based systems are better off
using the
commented versions
Dave
.
- Original Message -
From: James Hunkins [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 04, 2006 3:18 PM
Subject: [ql-users] bug in qlib_h C68 support file
Guys,
I think that I found a bug in the qlib_h include file used by C68.
Here are the details:
In the 'qdirect' structure, the member 'd_name' is defined as:
char d_name[36];
This works as long as the directory/file name is 35 or fewer
characters and holds a properly terminated C string (terminates with
a '0'). However, if the total name length is actually 36
characters,
then there is no termination. As far as I can tell the structure
does properly hold everything and isn't corrupt, just no termination
in that one case.
This might explain why in a few problems with long file names, I see
handling problems but not in others (compiled in C68 versus assembly
or compiled SBASIC for example?).
If I am correct this structure should define it as:
char d_name[37];
to allow room for the termination character of a C string.
Jim
___
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
___
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] Updated web site
In message [EMAIL PROTECTED], gwicks [EMAIL PROTECTED] writes - Original Message - From: Malcolm Cadman To: [EMAIL PROTECTED] Sent: Saturday, September 02, 2006 6:06 PM Subject: Re: [ql-users] Updated web site How do you know as to whether other Opera hits weren't also appearing as IE ? I realise this and what makes it worse is that by default Opera claims to be IE. Where the above is important is that it shows a quite a few Opera users do not have an up to date version. Opera appears to have been updated more frequently than the other browsers. Ah ... This discussion has stimulated me to have a look at Opera (v. 7.4) and I can see why you really like it. (The only other time I looked at an alternative browser was Netscape, and - heresy, heresy - I was not impressed.) It has some quite interesting features, and a nice clean appearance. Mozzila Firefox is worth a try too ... it also has a very simple and clean interface. Finally, I have a problem for you Opera experts. I can successfully import my favourites from IE but can't find a way of calling them up from within Opera. How do I do this? Opera has them as Bookmarks, you can also have sites that you use regularly as Tab's across the top bar of the Browser. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] MCALLT
Dilwyn Jones schreef: Does anyone have any experience of using MCALLT in Easyptr? SNIP Hi Dilwyn, You could download Per Witte's 'POP2.zip' from http://www.bixio60.org. François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] MCALLT
Hi Dilwyn, Does anyone have any experience of using MCALLT in Easyptr? I'm looking for a few examples of making use of the timeout and events (general tinkering), and perhaps for adding help 'bubbles' to my programs. I have suqcessfully adapted the help/hint example, as Per Witte described it in QLToday v10i3, for Suqcess 2.04. However there were some unexpected differences with MCALL. 1) The timing of the pan/scroll arrows bars was affected. The rows in the AW moved 2 or 3 lines with one click instead of one. This was solved by Marcel (who else) with the latest version of ptrmenr_cde v4.10. So make sure you use the latest version if you use scrollable AW items. 2) I also used: key=MCALL(#ch%,...): PVAL #ch%,erg% and then I checked erg%(16) for the Wake key (CF2), for which there was no Loose Item. This doesn't work with MCALLT. Marcel suggested the following: ev% = 64 key = MCALLT(#ch, ev%, 50) SELect ON key = -1280: REMark Timeout or event IF ev% = 64 THEN [...] CTRL+F2 END IF IF ev% = 0 THEN [...] Timeout END IF END SELect I gave Wake its own LI anyway. Hopefully this is of some help. Bob Spelten -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] MCALLT
Dilwyn Jones schreef: Does anyone have any experience of using MCALLT in Easyptr? SNIP Hi Dilwyn, You could download Per Witte's 'POP2.zip' from http://www.bixio60.org. François Van Emelen Thanks François, Bob and Marcel for your quick replies. Who's site is that, BTW? I'd forgotten about Per's article :o| - I'll go back to Toady have a look at that. And thanks to Marcel for the manual text, clarifies some things quite a bit, especially the event 'nybble' being a 'byte', or 'words' to that effect ;-) -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 0.0.405 / Virus Database: 268.11.7/436 - Release Date: 01/09/2006 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
