Re: [ql-users] I'm home, dear.
In a message dated 16/01/05 11:04:53 GMT Standard Time, [EMAIL PROTECTED] writes: Yes, I agree that these would be fine for our purposes IF IT WERE NOT FOR ONE PROBLEM. PROG_USE and DATA_USE are system wide settings and cannot vary between programs. If you launch one program it could read the current PROG_USE and DATA_USE settings at the time that it is started, but again, you have to presume that the user is going to alter these every time that a program is started. This is not exactly user friendly. Certainly it is not user friendly. I used to write programs which left an altered DATAD$ and PROGD$, This annoyed me considerably so I rewrote the programs to replace the original DATAD$ and PROGD$, even if an error had occurred (by using WHEN_ERROR). Incidentally I used to get annoyed too when PROGD$ wouldn't allow me to EX my NET_PEEK program. What I did in that case was to make NET_PEEK either EXecutable (which needs a path) or LRESPRable (to a THING) so that EXEP will find it whatever PROGD$. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
ONE PROBLEM. PROG_USE and DATA_USE are system wide settings and cannot vary between programs. If you launch one program it could read the current PROG_USE and DATA_USE settings at the time that it is started, but again, you have to presume that the user is going to alter these every time that a program is started. This is not exactly user friendly. It would be nice if PROG_USE and DATA_USE settings could be local to each job. If anyone ever attempts ot add this, perhaps the neatest way would be for them to start off with a copy of the default global settings, but for any DATA_USE and PROG_USE commands issued by a job to have a way of setting its own local values. You would then need a way of setting the global ones separately, so perhaps an extra parameter to DATA_USE etc? -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/01/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
I mean things like .. and \ (root directory) of DOS. Yes!! Ok, so at least one likes my idea :-) Two, I hope? Three now, I like the idea of having '..' etc too! Shouldn't we just decide on a suggested value now instead of making it dynamic (things like configuration options can't be dynamic anyway)? Windows has a max path length of 260 characters for example (UNC names can actually be longer, but hardly anybody uses them for local files). As long as it is a reasonable limit. Sure. What's reasonable for you? How about using the same as the enhanced ISO9660 standard (Joliet)? That might be one complication less. Then one day should we ever have CD writing it'll be in place and ready! -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/01/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
In a message dated 14/01/05 20:09:29 GMT Standard Time, [EMAIL PROTECTED] writes: stack (a7) channel count channels command string magic (.w) - (a6,a5) (as at present) program's name length (.w) HD's length (.w) program's name bytes padding of above to 42 bytes Since there is nothing on the stack after the end of the parameter string, (A6,A5) can be said to point either to the end of the parameter string or to the bottom of the stack. I have alwys treated (A6,A5) as pointing to the bottom of the stack and this seems more logical to me than to say that it points to the end of the parameter string. I would then think it better to find the new information by looking to the end of the parameter string. After all, you can't use (A6,A5) to get to the parameter string itself, you have to look to the end of the channel info. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz wrote: Moreover, Joachim said on this list that there is a mechanism in the heap allocation/release whereby a call would be made to some user specified code when the mem is released. I can't find this facility anywhere, thgough. All that exists, AFAIK, is an address that will be set when the memory is released. No, he's right. He's reffering to the chp_drlk entry, which must point to a fake driver definition block (only iod_clos needs to be set, which will be called when the memory gets freed). Actually this is exactly the way the thing system works, too. Check out util_thg_usage_asm, specifically th_addu. What is not trivial? The implementation? Yes. But fortunetaly that can be done later. Exactly, that's the nice thing with that solution. Incidentally, I don't know the DUP DDOWN commands. Actually I've never used them either. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
P Witte wrote: Even though it is my idea this probably needs more thinking. The device I proposed is probably not the way to go, instead perhaps the OPEN routine would need to be changed to automatically make use of the current directory, otherwise it's probably somewhat pointless. BUT if this were so, relative path-names would have to be introduced, too. I mean things like .. and \ (root directory) of DOS. Yes!! Ok, so at least one likes my idea :-) Shouldn't we just decide on a suggested value now instead of making it dynamic (things like configuration options can't be dynamic anyway)? Windows has a max path length of 260 characters for example (UNC names can actually be longer, but hardly anybody uses them for local files). As long as it is a reasonable limit. Sure. What's reasonable for you? As usual, relatively few people have commented on this... Which sometimes can be a good thing ;-) I heard that! ;) That's ok, wasn't about you anyway ;) Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: But why? Its enough to know it can be done without knowing how ;) OK, so this whole discussion makes no sense, I should just have gone ahead... That does not follow. The point of the discussion is not to fall into fixed ideas before all the issues have been explored. Now is the time to chop and change and take a few wrong turns, as we dont have the code base to drag around. Im trying to understand the present state of play, so how do you see the question of Qdos compatibility and any consequences? Should a Current Directory [CD] be included with the HD or is this a different project? How do filename/path limits affect this project? And how can we be expected to come up with solutions before we even agree on what it is were trying to do? You may know exactly what it is you want to do. Marcel's ideas appear to be somewhat different (as this discussion revealed) I have an inkling of what I want but I dont know if anyone else wants it. Are we even really talking about the same project? That the implementation ideas are different is obvious. Does the implementation affect the functionality or does the functionality dictate the implementation? Or do we have the Supermarket syndrome ie a number of different choices that produce identical results. Which to chose? The cheapest, the strongest or the sexiest? Practical people dont like being held up by planning and philosophical considerations. And yes, there is a risk of it all running into the sand if theres too much talk and too little action. But I believe the optimal solution will only be found if we take the trouble to search for it. It doesnt matter if we have to wait another year, its just a fraction of what weve waited so far. The CD issue cropped up as we were talking of HD. But how about other things while we are toying with the idea of doing something about jobs? It would, for example, be great for a job to have some kind of Quit code: When a job is removed it can either be called with a soft request (which the job could reject or delay, eg as a result of user input Save file before quitting Y/N?) or a hard request, which would allow it a few seconds to prepare itself for death after which it would be snuffed out without further ado, ready or not. Maybe we need an overall development plan before we continue poking around? More seriously, I don't pretend to know it all and if you have a better idea, I (generally) don't suffer from the NIH syndrome. What is the NIH syndrome? Actually I can think of one sure method to find a Home Directory [HD] string. Taking the structure to look like this: I think I can answer all your questions, but I doubt it would be very useful at this stage. Moreover, Joachim said on this list that there is a mechanism in the heap allocation/release whereby a call would be made to some user specified code when the mem is released. I can't find this facility anywhere, thgough. All that exists, AFAIK, is an address that will be set when the memory is released. This is not documented anywhere to my knowledge. Details would be welcome. The key file Common Heap header (smsq/keys/chp) mentions a chp_orel Offset of pointer to RELease code from chp_drlk Is that it? Incidentally, I don't know the DUP DDOWN commands. Whilst I have no problem understanding the DUP command (after all there is only one parent dir), am correct in assuming the DDOWN command has one obligatory parameter, the name of the dir? No, the name of the next sub dir: DATA_USE 'win1_prg' DDOWN 'ext' PRINT DATAD$ would print win1_prg_ext_ on your screen. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
On 15 Jan 2005 at 13:50, P Witte wrote: (...) Im trying to understand the present state of play, so how do you see the question of Qdos compatibility and any consequences? Should a Current Directory [CD] be included with the HD or is this a different project? How do filename/path limits affect this project? Implementing it as a thing means I can makje a standalone version for Qdos. The filenames etc don't impact this IF it is done is such a way that the filename don't have a limited length. I'm even doubtfull about reasonable lengths. If the memory isn't of a fixed size (and in the Thing scheme there is no reason that it should be) then the filename lengths becomes irrelevant. The only time it does become relevant is when it is supposed to be passed to the job. And how can we be expected to come up with solutions before we even agree on what it is were trying to do? You may know exactly what it is you want to do. Marcel's ideas appear to be somewhat different (as this discussion revealed) I have an inkling of what I want but I dont know if anyone else wants it. Ah, but then I have the privilege of coding it. he, he... Are we even really talking about the same project? That the implementation ideas are different is obvious. Does the implementation affect the functionality or does the functionality dictate the implementation? Or do we have the Supermarket syndrome ie a number of different choices that produce identical results. Which to chose? The cheapest, the strongest or the sexiest? I'd go for the sexiest any time, but that may be due to the fact that I live in France. More seriously, we're all trying to go in the same direction, even if we implement it differently (there is no right/wrong solution there, I think). What we want is a home directory. That is the dir the prog was executed from a home filename if I may call it that, i.e. the total name of the file that was executed (if possible, re: executable things). both of these are notaionally immutable. a current directory. Something that starts of as the home directory, but may be manipulated by the job itself. Practical people dont like being held up by planning and philosophical considerations. And yes, there is a risk of it all running into the sand if theres too much talk and too little action. But I believe the optimal solution will only be found if we take the trouble to search for it. It doesnt matter if we have to wait another year, its just a fraction of what weve waited so far. Yes and no. We can always talk more, but at some stage we're (I'm) going to start actually doing something... Moreover, perhaps we shoukd differentiate between the desgin concept (what we want/need) and the implementation. The CD issue cropped up as we were talking of HD. But how about other things while we are toying with the idea of doing something about jobs? It would, for example, be great for a job to have some kind of Quit code: When a job is removed it can either be called with a soft request (which the job could reject or delay, eg as a result of user input Save file before quitting Y/N?) or a hard request, which would allow it a few seconds to prepare itself for death after which it would be snuffed out without further ado, ready or not. OK why not. But, to my mind, this is a totally separate issue. There was also the issue Jochen had raised on this list some time (years?) ago: SOme form;of interrupting a job that is doing some long processing. But, as I said, this is, at least to my mind, something different. Let's keep with the policy of the little steps Maybe we need an overall development plan before we continue poking around? Again, yes and no. Yes, an overall development plan would be great. No, it isn't such a good idea because we here on this list will NEVER agree on something like that. Also, a development plan is all very nice, but who will do the development? The state of SMSQE development so far has always been that those who want to participate - do. If we have some kind of development plan then we need some coordinator who forces people to do what is necessary... More seriously, I don't pretend to know it all and if you have a better idea, I (generally) don't suffer from the NIH syndrome. What is the NIH syndrome? Not Invented Here. :-)) (...) parent dir), am correct in assuming the DDOWN command has one obligatory parameter, the name of the dir? No, the name of the next sub dir: (that's what I meant) DATA_USE 'win1_prg' DDOWN 'ext' PRINT DATAD$ would print win1_prg_ext_ on your screen. Yes, thanks 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.
Wolfgang Lenerz schrieb: What we want is a home directory. That is the dir the prog was executed from a home filename if I may call it that, i.e. the total name of the file that was executed (if possible, re: executable things). both of these are notaionally immutable. a current directory. Something that starts of as the home directory, but may be manipulated by the job itself. hhm .. just to say what i'd like to have or i think what would be usefull (and i am a os programming nobody - i just play around in SBasic) a private PROGD$ a private DATAD$ as well as ../ wolfgang ... ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
P Witte wrote: DATA_USE 'win1_prg' DDOWN 'ext' PRINT DATAD$ would print win1_prg_ext_ on your screen. I should add: Whether it exists or not, ie it appears to be a simple string operation. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Marcel Kilgus writes: I mean things like .. and \ (root directory) of DOS. Yes!! Ok, so at least one likes my idea :-) Two, I hope? Shouldn't we just decide on a suggested value now instead of making it dynamic (things like configuration options can't be dynamic anyway)? Windows has a max path length of 260 characters for example (UNC names can actually be longer, but hardly anybody uses them for local files). As long as it is a reasonable limit. Sure. What's reasonable for you? How about using the same as the enhanced ISO9660 standard (Joliet)? That might be one complication less. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
George writes: stack (a7) channel count channels command string magic (.w) - (a6,a5) (as at present) program's name length (.w) HD's length (.w) program's name bytes padding of above to 42 bytes Since there is nothing on the stack after the end of the parameter string, (A6,A5) can be said to point either to the end of the parameter string or to the bottom of the stack. I have alwys treated (A6,A5) as pointing to the bottom of the stack and this seems more logical to me than to say that it points to the end of the parameter string. I would then think it better to find the new information by looking to the end of the parameter string. After all, you can't use (A6,A5) to get to the parameter string itself, you have to look to the end of the channel info. I see your point and agree. It shouldnt affect compatibility except possibly in the case of QLib, who's workings we dont know. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: 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. What are they?. I dont have a hot_rext (or similar) command. If this is contained in some toolkit, then that toolkit should be altered, not the system. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Marcel Kilgus writes: Also something one should probably think about: should functions like OPEN automatically use the current directory if no drive name is given? Currently most commands default to DATAD$. Or, speaking completely into the blue, what about a meta device like DEV_ that uses dynamic paths instead of static ones? Something like home_MyDataFile? The DEV device doesnt seem to work like that: If you have a directory structure like win1_ps_ - win1_ps_letter_doc win1_ps_pt_ - win1_ps_pt_letter_doc If you set DEV_USE 1, 'win1_' then you can OPEN, or whatever, dev1_ps_letter_doc and dev1_ps_pt_letter_doc. All well and good. If you set DEV_USE 1, 'win1_ps_' then Qpac2 or OPEN finds dev1_letter_doc (= win1_ps_letter_doc) ok, as youd expect, but it cant find dev1_pt_letter_doc. You better check out whether DEV's behaviour is what you expect. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
On 14 Jan 2005 at 11:54, P Witte wrote:
(...)
What are they?. I dont have a hot_rext (or similar) command. If this is
contained in some toolkit, then that toolkit should be altered, not the
system.
yes, you do :-)
eg ert hot_rext(' f ',' win1_progs_fifi ').
Sets FiFi up as a hotkey (in fact an executable thing). Hit Alt F and FiFi
excutes. But what would its home dir be?
Wolfgang
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] I'm home, dear.
On 14 Jan 2005 at 15:03, Wolfgang Lenerz wrote: yes, you do :-) No you don't. I meant hot_res, of course. Woflgang 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.
Wolfgang Lenerz wrote: 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... Very well :-) I'm willing to contribute, perhaps in adapting the clients. I'm not promising anything quick, though. Not needed. Better something well thought out and well written. Also some new questions or requests will surely arise during the development. 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) Very essential and certainly in itself already worthwile. the current dir which will initially be the home dir Even though it is my idea this probably needs more thinking. The device I proposed is probably not the way to go, instead perhaps the OPEN routine would need to be changed to automatically make use of the current directory, otherwise it's probably somewhat pointless. BUT if this were so, relative path-names would have to be introduced, too. I mean things like .. and \ (root directory) of DOS. What my aim is with all this: the biggest bother for me with the SMSQ/E file system is that all paths always have to be absolute. I'd like for example to copy my sources from src_x to src_y and still be able to compile them. Real life example: when I did UDPNet I wanted it to be separate from SERNet, which is here in win1_progs_midi_s_. But it is not enough to copy all sources to win1_progs_midi_u_, instead I have to alter basically every single file to reference midi_u now. Actually this was too much of a bother for me and I just altered the SERNet sources. 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). Shouldn't we just decide on a suggested value now instead of making it dynamic (things like configuration options can't be dynamic anyway)? Windows has a max path length of 260 characters for example (UNC names can actually be longer, but hardly anybody uses them for local files). set a default filename for a job with a certain name How do you know the job name? When using HOT_whatever, don't you just know the filename then? As usual, relatively few people have commented on this... Which sometimes can be a good thing ;-) Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
In a message dated 14/01/05 00:12:56 GMT Standard Time, [EMAIL PROTECTED] writes: the complete filename the dir whence it came from (home dir) the current dir which will initially be the home dir This is just a semi-thought. If a file is called win1_d1_twaddle and there is no directory called win1_d1_ then the home directory is win1_. Now, while the program is in operation someone types MAKE_DIR win1_d1 and presses ENTER. The directory of the file is now win1_d1_. Does this worry anyone? George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
On 14 Jan 2005 at 16:38, Marcel Kilgus wrote: (...) Very well :-) I'm willing to contribute, perhaps in adapting the clients. yes QPAC2. Does anybody have a valid email address for Thierry Godefroy. It would be nice to adapt FileInfo II, too. (...) Even though it is my idea this probably needs more thinking. (...) OK, no problem, I can always think (I think) Anyway, If I impelment it as as thing with a separate extention for the current dir, this should be OK. (...) Shouldn't we just decide on a suggested value now instead of making it dynamic (things like configuration options can't be dynamic anyway)? Windows has a max path length of 260 characters for example (UNC names can actually be longer, but hardly anybody uses them for local files). I don't mind either way. set a default filename for a job with a certain name How do you know the job name? When using HOT_whatever, don't you just know the filename then? Yes. The scheme I image is a bit longwinded, as follows: The user sets up a prog on a Hotkey, using Hot_res or any oif the hot_ (I hope this word will not get this email censored) keywords. The user presumably knows what the job will be called once it exists after having been executed from the hotkey. he then tells the home thing that for a job of that name, the home dir should be . This can be done ONCE in the boot file. Later he fires off the job with the hotkey (and I won't start changing the hotkey system!!!). The job interrogates the home thing to see what its dir is, by providing the home thing with its job ID. Of course, the home thing *should* reply that it doesn't have a home dir since the hotkey itself didn't register the job with the home thing. Instead of this, the home thing could get the job's filename (since it has the job ID, it can get at the jcb and from there the job name - in a way similar to the one I presume QPAC2 JOBS menu does it - the job name is supposed to lie a xxx bytes after the start of the job which lies xxx bytes after the jcb). Then is checks whether a default haome dir has been set up for a job with this name. This should work except for jobs whose name changes, e.g QD - but it probably doesn't change before the home thing is called) This is longwinded, of course. The alternative is to change the hotkey routines.. I'm NOT sure I'll want to poke into there - also, the hotkey routines would have to be amended in such a way as to set up a repository for filenames itself. This seems to be double the work. As usual, relatively few people have commented on this... Which sometimes can be a good thing ;-) lol 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.
On 14 Jan 2005 at 11:22, [EMAIL PROTECTED] wrote: (...) This is just a semi-thought. If a file is called win1_d1_twaddle and there is no directory called win1_d1_ then the home directory is win1_. Now, while the program is in operation someone types MAKE_DIR win1_d1 and presses ENTER. The directory of the file is now win1_d1_. Does this worry anyone? Err, in short - no. And anyway, who would call a file twaddle? 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.
Marcel Kilgus writes: Even though it is my idea this probably needs more thinking. The device I proposed is probably not the way to go, instead perhaps the OPEN routine would need to be changed to automatically make use of the current directory, otherwise it's probably somewhat pointless. BUT if this were so, relative path-names would have to be introduced, too. I mean things like .. and \ (root directory) of DOS. Yes!! 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). Shouldn't we just decide on a suggested value now instead of making it dynamic (things like configuration options can't be dynamic anyway)? Windows has a max path length of 260 characters for example (UNC names can actually be longer, but hardly anybody uses them for local files). As long as it is a reasonable limit. set a default filename for a job with a certain name How do you know the job name? When using HOT_whatever, don't you just know the filename then? As usual, relatively few people have commented on this... Which sometimes can be a good thing ;-) I heard that! ;) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes:
What are they?. I dont have a hot_rext (or similar) command. If this is
contained in some toolkit, then that toolkit should be altered, not the
system.
yes, you do :-)
eg ert hot_rext(' f ',' win1_progs_fifi ').
Sets FiFi up as a hotkey (in fact an executable thing). Hit Alt F and FiFi
excutes. But what would its home dir be?
win1_progs_ ?
Per
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: 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!!! But why? Its enough to know it can be done without knowing how ;) Actually I can think of one sure method to find a Home Directory [HD] string. Taking the structure to look like this: stack(a7) channel count channels command string magic (.w) - (a6,a5) (as at present) program's name length (.w) HD's length (.w) program's name bytes padding of above to 42 bytes Algorithm: get job info find start of allocated memory list scan through list: if memory ID my ID: next if length of block 52 bytes: next if the word at block_length - 48 magic: next HD found: exit scan end scan Another way would be to analyse QLib_rext or trace a running program to determin whether QLib retains any memory of its original data area. If it does, say in a6, then all that is needed to find the HD string is the correct offset. If it doesnt, eg it releases this memory again, this method wont work. A third way would involve a hybrid between the Thing and the Stack schemes: Let the EX code link the dataspaces of all jobs under its auspices using part of the area to store its information. No need to reserve an additional memory area whenever a job is started. Thus a different structure could be used: stack(a7) channel count channels command string Link to next dataspace (.l) - (a6,a5) (as at present) Any other household info the Thing needs program's name length (.w) HD's length (.w) program's name bytes padding of above to max bytes Any Other Business Remember, all this dataspace is invisible to legacy programs. The memory is perfectly legally there, but the legacy program wouldnt know anything about it. No marker is needed because all data is at known offsets. The mechanism would be the same as I understand you were thinking; that when a job is removed, the Thing is freed. The Free rutine unlinks the dataspace and the kill job function (sms.frjb) releases the memory. So its clean, lean, less messy than having a different memory area to store the details, compatible with legacy software, and cognizant programs running on a legacy OS will be warned unless the Thing is there. (...) 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. What is not trivial? The implementation? or reusing DUP/DDOWN? As for the principle, I believe that is what Marcel is proposing with his Current Directory. [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... That was a very discreet one ;) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
On 14 Jan 2005 at 20:08, P Witte wrote: (...) But why? Its enough to know it can be done without knowing how ;) OK, so this whole discussion makes no sense, I should just have gone ahead... More seriously, I don't pretend to know it all and if you have a better idea, I (generally) don't suffer from the NIH syndrome. Actually I can think of one sure method to find a Home Directory [HD] string. Taking the structure to look like this: stack(a7) channel count channels command string magic (.w) - (a6,a5) (as at present) program's name length (.w) HD's length (.w) program's name bytes padding of above to 42 bytes Algorithm: get job info find start of allocated memory list scan through list: if memory ID my ID: next if length of block 52 bytes: next if the word at block_length - 48 magic: next HD found: exit scan end scan Yes, that would be one way. Several remarks here: There is no guarantee that a word wouldn't be occurring naturally, it would have to be a long word at least. Why 52 bytes? Let's cater for longer filenames immediately. Scanning this list will probably take longer than fnd the thing. It doesn't take care of the current prog string.. Another way would be to analyse QLib_rext or trace a running program to determin whether QLib retains any memory of its original data area. If it does, say in a6, No need to check Qlib for that. When it comes to your keyword, it'll emuate Sbasic, i.e. point to a basic area in A6. We also know that A3 A5 point to the parameter list (...) Thus a different structure could be used: (...) I'm not sure what happens first: relase of the memory, or freeing of the thing... Moreovern this would means that the job continues to use the thing during its entire lifetime. And anyway, if you start implementing a thing, let's go the whole hog. Moreover, Joachim said on this list that there is a mechanism in the heap allocation/release whereby a call would be made to some user specified code when the mem is released. I can't find this facility anywhere, thgough. All that exists, AFAIK, is an address that will be set when the memory is released. (...) 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. What is not trivial? The implementation? Yes. But fortunetaly that can be done later. Incidentally, I don't know the DUP DDOWN commands. Whilst I have no problem understanding the DUP command (after all there is only one parent dir), am I correct in assuming the DDOWN command has one obligatory parameter, the name of the dir? (...) That was a very discreet one ;) Always the diplomat, I. 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.
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.
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] I'm home, dear.
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.
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.
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.
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.
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.
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: Re: [ql-users] I'm home, dear.
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: Re: [ql-users] I'm home, dear.
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.
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.
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.
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.
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] I'm home, dear.
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.
In message [EMAIL PROTECTED], Wolfgang Lenerz [EMAIL PROTECTED] writes clip 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] I'm home, dear.
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] I'm home, dear.
On Wed, 12 Jan 2005 07:03:39 +0100, Wolfgang Lenerz [EMAIL PROTECTED] wrote: 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. 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) 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. 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 Simple. Open_dir win1_basic_exts_turbo_config_exe. Get the name of the resulting file. This will be the directory name (!). OK - thanks to everyone I had forgotten about FNAME$ -- 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.
Wolfgang Lenerz wrote: How do you find this string? Have you tried finding the command string from a QLibbed prog other than with the QLib internal CMD$ command? The problem is that once you get to the stage where your keyword will be invoked, A5 will point to who knows what (in fact, the parameter list, relaive to A6) I see no safe way to find the string - but I stand to be corrected! Donning my Geoff Wicks constructive subversive hat, here's a wacky suggestion: Define a new system variable (Heretic!) that points to a table of pointers, indexed by job number, that each point to a job data block. As usual, a zero pointer would mean that no data block exists for that job. The job data block could potentially contain lots of useful per-job information and could be located anywhere in memory - beyond the job's stack, between the job's code and data areas, in the common heap... John ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Dilwyn Jones wrote: I look forward to it, and I don't really care how it's written as long as my little new programs can do something like: Careful, Dilwyn - that's the sort of attitude that made Windows what it is today! One of the advantages of SMS* being under the control of one person was that a degree of conceptual integrity could be maintained. Now that more people are involved, I think it's important to strive to retain the spirit of the original design in any new developments. Marcel's work on WMAN is a excellent example of how this can be achieved. John ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: 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. My notes say (a6,a5) points to the top of the data area, not the command string? However, it is not important. A new convention could specify that (a6,d3) (or whatever), would point to the marker. Am I right in assuming that, apart from the registers that are defined (a4-a7), all other registers are zeroed on job initialisation accross all Qdos-compatible systems? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: 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! True ;) I really only meant that it should operate in an intuitively identical manner considering the differences between the interpreted and compiled environments. That is why Im suggesting to use the Save Name as the Homedir in the interpreter. The difficult bits have already been implemented, only we dont currently have access to the Save Name except indirectly through (Q)SAVEing and (Q)LOADing the current program. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: Or a completely different proposal: (putting the home dir after the command string) As long as you dont mean that this has to be done on the EX command line, I agree with the above description. Having said that, it /would/ perhpas be nice to add something like this as an option to overwrite the default home directory, although is does complicate an already overloaded parameter list: EX filename ; command string ! different homedir (...) 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 other, more plodding, ways to find a job's data area and locate the HD string. Thus a function such as HOMED$ or CDIR$ to read the HD string would have to work differently in compiled and interpreted mode. Thereyougo. Now shoot it down in flames! OK. Flamethrower mode I'd thought of that, too. The only problem I see with it is, indeed Qlib. I presume that your way of doing it would involve some kind of basic keyword that you call and that returns the home dir string. Precisely How do you find this string? Have you tried finding the command string from a QLibbed prog other than with the QLib internal CMD$ command? The problem is that once you get to the stage where your keyword will be invoked, A5 will point to who knows what (in fact, the parameter list, relaive to A6) I see no safe way to find the string - but I stand to be corrected! Its first of all a matter of finding the job's dataspace. The Homedir string is at the top of that, past where the QLiberated job has any legitimate business to poke around (it thinks its dataspace (according to my scheme) is 48 bytes smaller than it in actual fact is). So QLib initialisation code is unlikely to scribble over it. (Ive just briefly checked: A QLibbed program doesnt appear to interfere with its command line either, so thats hopeful.) I havent looked in detail how the dataspace may be found, but I presume it possible to find any executing job's dataspace by legitimate means. It is also possible that the QLibbed job's a6 points to its dataspace. Either that or it stores the its location somewhere, as it needs to find its own command string on demand. Alternatively, EX could be made to identify a QLibbed program and store its dataspace address in a known safe location before activation. This requires investigation, but Im not concerned that it wont be possible. / flamethrower mode Better to flame now than once it is implemented ;) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: 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... Wouldn't it be better if the user explicitly set default home dirs per job name? Doesnt this defeat the object? We already can do this with a simple Config block. The point of a Homedir is that you can always know the name and path of the current job from wherever it is executed. (BTW, by supplying the name too, it would allow the program to poke its own binary on disk, eg for configuration purposes). Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] I'm home, dear.
I look forward to it, and I don't really care how it's written as long as my little new programs can do something like: Careful, Dilwyn - that's the sort of attitude that made Windows what it is today! Aarrgghhh. Forget I ever said that Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
On 12 Jan 2005 at 13:20, P Witte wrote: (...) That is why Im suggesting to use the Save Name as the Homedir in the interpreter. The difficult bits have already been implemented, only we dont currently have access to the Save Name except indirectly through (Q)SAVEing and (Q)LOADing the current program. Oops, in this case I don't understand at all what you are talking about. What is the save name? Wolfgang 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] I'm home, dear.
On 12 Jan 2005 at 13:25, P Witte wrote: (...) As long as you dont mean that this has to be done on the EX command line, I agree with the above description. No, that wouldn't make much sense. Having said that, it /would/ perhpas be nice to add something like this as an option to overwrite the default home directory, although is does complicate an already overloaded parameter list: EX filename ; command string ! different homedir Before IMPROVING the service, let's already get it... (grin) (...) Its first of all a matter of finding the job's dataspace. No,no! To recap: job start (a6) (generally a bra to the real code) pointed to by A6 on job execution code area ... data area (a6,a4) stack (a7) containing nbr of channels channels command line(a6,a5) So the command line doesn't lie in the data area itself, but above the stack (the diagram above is upside down). So a pointer to the dataspace doesn't make any sense, you don't know how large your dataspace is (once the program executes, the loader does, though). A normal prog should be able to find its command string as it should 'know how it has manipulated its own stack. But a compiled basic prog? Nothing points to it anymore. If one were *sure* there is nothing on the stack, one might even get at it through the stack pointer. which, after all, lies just above the commnd string and thus the home dir in this scheme. One way around it: precede the home dir with a unique long word and search for that in the stack area. This presumes that the home dir is of a fixed maximum length The Homedir string is at the top of that, past where the QLiberated job has any legitimate business to poke around legitimate. Says it all (...) I havent looked in detail how the dataspace may be found, but I presume it possible to find any executing job's dataspace by legitimate means. It is also possible that the QLibbed job's a6 points to its dataspace. Either that or it stores the its location somewhere, as it needs to find its own command string on demand. Nope, see above Alternatively, EX could be made to identify a QLibbed program and store its dataspace address in a known safe location before activation. Err, like what? And how do you get at it from within your basic keyword (which should also work for normal uncompiled basic) (...) Better to flame now than once it is implemented ;) Of course. We're far from it, anyway 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] I'm home, dear.
On 12 Jan 2005 at 13:26, P Witte wrote: (...) Doesnt this defeat the object? We already can do this with a simple Config block. The point of a Homedir is that you can always know the name and path of the current job from wherever it is executed. I think we were talking about jobs executed from things which don't have a filename. Weren't we? (BTW, by supplying the name too, it would allow the program to poke its own binary on disk, eg for configuration purposes). OK, sure. I think Marcel said something similar, too- the dir name and the total name of the file. 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.
P Witte wrote: Theres no stack hack involved; simply a new convention. Well, the more I think about it, the less I like it. A thing could be a much cleaner, better maintainable and extendable solution. I suspect you may have the path depth/filename length issue at the back of your mind. No, I have for example a current directory in mind, which should be changeable (on request of the application) after the application started to run. I also have a device in mind that automatically accesses the current directory. None of which is cleanly doable with the put it into data space method. As soon as a job runs the data space is his to mess with, nobody else. How should a potential device find the directory name there? And, thinking further, the thing could even do more. It could supply the complete filename of the EXE, it could supply the path of the EXE (home directory) AND it could supply a current directory. All with very little effort. Then it could offer services like change directory, a bit like DUP and DDOWN. A third party (like the mentioned device) could easily get the directory for another job, without any guessing. All neat and clean. And how do you know the OS does provide all those directory services? Easy, if it didn't, there would be no thing! Can't say the same about (A6,D3.L) or something similar. My proposal is less likely to fragment memory and would use less of it (M/c programs could simply use the memory reserved for the HD if it were not required). 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. 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. That's why an independent interface like a thing could really help. It can be accessed from any language because it does not rely on any information but the job-ID, which is always readily available. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] I'm home, dear.
Dilwyn Jones wrote: Aarrgghhh. Forget I ever said that Said what? :-) John ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
On 12 Jan 2005 at 14:31, John Hall wrote: (...) True. (And, of course, your Thing could potentially be extended to store any number of per-job data items.) Yes, Marcel has seen the potential of it immediately. It's just that, for some reason, what we're trying to achieve doesn't seem to me to be a Thing sort of thing :-) :-) If you look at a typical thing list in SMSQE, you will find things such as flp control, win control, Keyboard, Hotkey etc All thing things. (and anybody who lisps when reading this goes to Singsing immediately, without going by start and collecting...) 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.
In a message dated 11/01/05 16:54:46 GMT Standard Time, [EMAIL PROTECTED] writes: 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 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. I don't know about Turbo, but since that is still maintained, something should be possible there (George?). Turbo uses OPTION_CMD$ to return the parameter string of an EXecuted program. This keyword is, of course, part of Turbo TK code, and returns a null string in SuperBASIC. If a new Turbo TK keyword is neede for home$ I presume this could be added. However, if home$ is just another SuperBASIC keyword Turbo would presumably allow it to be compiled (provided it did not return paramters!). George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: That is why Im suggesting to use the Save Name as the Homedir in the interpreter. The difficult bits have already been implemented, only we dont currently have access to the Save Name except indirectly through (Q)SAVEing and (Q)LOADing the current program. Oops, in this case I don't understand at all what you are talking about. What is the save name? 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. I propose that this name be accessed from Sbasic via the a function like HOME$ or HOMEN$ or whatever, and the path be accessed via HOMED$ (to follow the current nomenclature). Perhaps it should be possible to change it directly (rather than indirectly as now): HOME_USE win1_new_john_bas. In compiled mode HOME$, HOMED$ and HOME_USE would all act upon the home directory. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: Doesnt this defeat the object? We already can do this with a simple Config block. The point of a Homedir is that you can always know the name and path of the current job from wherever it is executed. I think we were talking about jobs executed from things which don't have a filename. Weren't we? Sorry if I misunderstood. 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. (BTW, by supplying the name too, it would allow the program to poke its own binary on disk, eg for configuration purposes). OK, sure. I think Marcel said something similar, too- the dir name and the total name of the file. Yes, theres no point in not doing so. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Marcel Kilgus writes: No, I have for example a current directory in mind, which should be changeable (on request of the application) after the application started to run. I also have a device in mind that automatically accesses the current directory. None of which is cleanly doable with the put it into data space method. As soon as a job runs the data space is his to mess with, nobody else. How should a potential device find the directory name there? Fair enough, but you are trying to solve a different problem to the one I was solving. Im not a mind reader. I never knew that I wanted a current directroy, but I can see that it makes sense. However, this is a much more ambitious project than a mere home directory affair. You have to alter the device driver to cater for it too. 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. There is nothing wrong with that per se, as long as we are concious of the fork in the road. My proposal would have allowed retro-fitting onto Qdos, either as a separate toolkit to replace EX co, or by upgrading the file version of TK2 should the sources ever become available. And, thinking further, the thing could even do more. It could supply the complete filename of the EXE, it could supply the path of the EXE This has been my thinking all along, too. (home directory) AND it could supply a current directory. All with very little effort. Then it could offer services like change directory, a bit like DUP and DDOWN. A third party (like the mentioned device) could easily get the directory for another job, without any guessing. All neat and clean. Very nice ;) 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. Equivalent functionality to DUP and DDOWN could be a system service and be applied to that string. The assembler programmer would have some assistance to maintain this file name string, but it wouldnt be a true Current directory. For the Sbasic programmer the illusion of a true Current dir could be made total, so he wouldnt be able to tell the difference between your Current dir solution and mine. And how do you know the OS does provide all those directory services? Easy, if it didn't, there would be no thing! Can't say the same about (A6,D3.L) or something similar. That was a simple suggestion to carry a more complex argument; not a solution, the best solution, the only solution or the whole solution. My proposal is less likely to fragment memory and would use less of it (M/c programs could simply use the memory reserved for the HD if it were not required). 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. 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. That's why an independent interface like a thing could really help. It can be accessed from any language because it does not rely on any information but the job-ID, which is always readily available. 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 ;) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
Wolfgang Lenerz writes: Having said that, it /would/ perhpas be nice to add something like this as an option to overwrite the default home directory, although is does complicate an already overloaded parameter list: EX filename ; command string ! different homedir Before IMPROVING the service, let's already get it... (grin) (...) Of course. But its good to peek around the corner - as we are doing - to see how it might affect the implementation. Its first of all a matter of finding the job's dataspace. No,no! To recap: command line (a6,a5) This is not the case. As it says in the documentation (and I have just varified it with Jmon) (a6,a5) points to the top of the data area (it says points to the top of the jobs area but this is a typo). It doesnt point to the command string (although the illustration seems to suggest that). (Qdos Bible, Section 3.0 pp 1-2) The top part of the data area is of course the stack. The language is perhaps a bit imprecise - at least to mere mortals like myself: When you set up a job manually from m/c you specify exactly how big the data area must be. That will include the amount of dataspace you require plus the size of stack you need. When EX sets up the job for you it uses the dataspace specified in the file header, but then adds at least one word (channel count), plus room for the actual number of channel IDs, plus enough space to contain the command string, if any, on top of that again. As the size of this cannot be known at compile time (its entirely up to the user, not the programmer) this has to be in addition to the fixed dataspace size you specified. Since all this is a single, contiguous block of memeory, consisting of the job's private data, it can justifiably be called the data area. 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. 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. I hope this clarifies matters. However, the point is moot at present, since it seems that at a different solution is currently the favourite. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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. 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. 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. The new colours for WMAN are sort of a hack, too, though I tried to design them as well as I could, but there the structures were already given, so not much choice. Actually the whole PE was and is a hack, albeit a very good one, so it fits right in ;-) And how do you know the OS does provide all those directory services? Easy, if it didn't, there would be no thing! Can't say the same about (A6,D3.L) or something similar. That was a simple suggestion to carry a more complex argument; not a solution, the best solution, the only solution or the whole solution. No offence meant, just wanted to give an example. The question is always how do I know I'm running on a system that provides the service I want. 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. 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. 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. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
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
Re: [ql-users] I'm home, dear.
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?).. 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. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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, so that, for example, it can find a configuration or data file in that directory. This facility as such doesn't exist in the QL world. I propose to incorporate it into SMSQE. The problem is one of compatibility, of course. Technically, various solutions could be considered, such as putting it after the command string, but all of them will face some obstacles, such as how to get at this from a compiled basic program. Concept =-=-=-=-= The solution I find most acceptable, would be to create a new Thing. This thing would hold the home directory string, and each job could get it from there. 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 activation)? Apart from anything else, this would maintain the self-cleaning property of the operating system... SNIP In today's everyday use, there seem to be several ways that programs are executed. - Via the EX, EW etc commands, which are part of SMSQE itself. These commands will have to be amended. - Via the Hotkey system. Unless a default home dir is set up explictly, jobs set up in this way won't have a home directory - Via QPAC2. This would have to be changed to send the home dir name to the thing. - Via other file managers (which ones?). They would have to be changed, too. If there are many of them, I might envisage creating a new trap (#3, D0 = $3F) which takes as parameter the name of a file excutes it (this is a facility which I find sorely missing from the OS as such anyway). Trap#3 functions deal with channel IDs, not device names. Shouldn't this be implemented as a vectored routine? John ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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 activation)? 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? By the time your (new) keyword to fetch the data has been called, what is on the stack will/might have been overwritten The only other job-associated data structure is the job header. I am NOT willing to bet on the number of programs out there that assume that this structure is $68 bytes long... (...) If there are many of them, I might envisage creating a new trap (#3, D0 = $3F) which takes as parameter the name of a file excutes it (this is a facility which I find sorely missing from the OS as such anyway). Trap#3 functions deal with channel IDs, not device names. Shouldn't this be implemented as a vectored routine? Well - whatever. It mixes trap#1 (creating a job), trap#2 (opening a channel), trap#3 (getting the file into mem). However, you just made mùe think of something - it isn't possible to call the job creation trap from withing another trap, in Supervisor mode (now where have I heard that before recently?) so a vectored routine it might be. wolfgang John ___ 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] I'm home, dear.
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 as with CMD$? Does CMD$ work in compiled basic? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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 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. I don't know about Turbo, but since that is still maintained, something should be possible there (George?). 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.
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 now aims a little bit higher, instead of having a home directory allowing a current directory (which can be-preset to the home directory), i.e. something dynamic, the stack debate becomes irrelevant as it's only suitable for static passing of data. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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 would have to be changed to send the home dir name to the thing. If it's easy enough to do no problem ;-) - Via other file managers (which ones?). They would have to be changed, too. CueShell, which I have acquired the sources for but didn't have a look at yet. If there are many of them, I might envisage creating a new trap (#3, D0 = $3F) which takes as parameter the name of a file excutes it (this is a facility which I find sorely missing from the OS as such anyway). 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 a #1 or #2 trap there will be no way to maintain QDOS compatibility (not that I'm particularly bothered by that, just mentioning it). Preliminary way the Thing could handle requests =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - set the home dir name -- get the true job ID if passed as -1 -- try to find this job ID in my list - if found, return with error - else, set up string (possibly reserve more mem in chunks of 512 bytes) As I said, I think if we/you are going ahead with this, I think it should probably be a current directory functionality with functions like up one directory and change directory to x (absolute and relative). Or perhaps both? On other systems Applications get 2 things: a current directory and the complete name of their EXE file. Some way must be devised to delete the filenames after a certain time. When the job is deleted? Yes. Should the home dir name be deleted once it has been passed back to the job? No. Should there be an explicit deletion? No. Should there be a normal request for the home dir (doesn't delete it) and one where deletion is automatically done after passing the name to the job? Don't see why (and as said, a current directory would have to be present during the whole process anyway). We're talking about a few bytes here. Also something one should probably think about: should functions like OPEN automatically use the current directory if no drive name is given? Currently most commands default to DATAD$. Or, speaking completely into the blue, what about a meta device like DEV_ that uses dynamic paths instead of static ones? Something like home_MyDataFile? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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 a #1 or #2 trap there will be no way to maintain QDOS compatibility (not that I'm particularly bothered by that, just mentioning it). See my other email (starting a job from a trap?) (...) As I said, I think if we/you are going ahead with this, I think it should probably be a current directory functionality with functions like up one directory and change directory to x (absolute and relative). Or perhaps both? On other systems Applications get 2 things: a current directory and the complete name of their EXE file. OK, this bears thinking about. (...) Don't see why (and as said, a current directory would have to be present during the whole process anyway). We're talking about a few bytes here. Ok, I hadn't envisaged the current dir as such. Also something one should probably think about: should functions like OPEN automatically use the current directory if no drive name is given? Currently most commands default to DATAD$. I HATE the open commands that append the data/prog dir when I don't want them! But I'm probably alone with that opinion. Or, speaking completely into the blue, what about a meta device like DEV_ that uses dynamic paths instead of static ones? Something like home_MyDataFile? Too ambitious? 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.
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) adds the space this data requires to the dataspace and stacks that data on top of the data area. 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. This could now be the pointer to the directory string (alternative registers could be used instead, if better). Since the data area is private to each instance of a job, the Home Directory [HD] could easily be dynamic, ie a Current Directory [CD] instead/as well. Id propose the following format for the HD/DC area: (magic word) full file name lengthword directory length word string bytes bytes padding to 42 bytesbytes There would have to be some way to flag that the HD/CD was present: eg an additional magic word at the top of the structure, or some other method. For Sbasic one could simply extend the Save Name (to call it something. That is the name that is stored somewhere when you SAVE your program) system currently in place. Ie some additional keywords to read or change the Save Name 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 other, more plodding, ways to find a job's data area and locate the HD string. Thus a function such as HOMED$ or CDIR$ to read the HD string would have to work differently in compiled and interpreted mode. Thereyougo. Now shoot it down in flames! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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 there are open channels or a command line the Basic keywords EX (and family) adds the space this data requires to the dataspace and stacks that data on top of the data area. 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. This could now be the pointer to the directory string (alternative registers could be used instead, if better). I prefer this type of approach as it would ensure that the home directory (or whatever) would be removed together with the job. However, I perceive several problems with this approach: 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 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 directory (ie file type 255). In other words, it would need to check whether the following were directory files and select the home directory as the first one it found with file type 255 win1_basic_exts_turbo_config_ win1_basic_exts_turbo_ win1_basic_exts_ win1_basic_ win1_ Since the data area is private to each instance of a job, the Home Directory [HD] could easily be dynamic, ie a Current Directory [CD] instead/as well. Id propose the following format for the HD/DC area: (magic word) full file name lengthword directory length word string bytes bytes padding to 42 bytesbytes There would have to be some way to flag that the HD/CD was present: eg an additional magic word at the top of the structure, or some other method. Yes, I can understand the need for this - it all depends on what points to the HD/CD -- 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.
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 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 completely made up my mind yet. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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 good choice IMO. But if you do use a #1 or #2 trap there will be no way to maintain QDOS compatibility (not that I'm particularly bothered by that, just mentioning it). See my other email (starting a job from a trap?) I wonder how sms.crjb ever managed to do it ;-) Anyway, a vector is probably a better idea, yes. Also something one should probably think about: should functions like OPEN automatically use the current directory if no drive name is given? Currently most commands default to DATAD$. I HATE the open commands that append the data/prog dir when I don't want them! Well, partly yes, some files do tend to show up at wrong places if I misspell a device name. On the other hand, I do prefer ex fifi over ex dev1_fifi. Or, speaking completely into the blue, what about a meta device like DEV_ that uses dynamic paths instead of static ones? Something like home_MyDataFile? Too ambitious? As usual code reuse is the magic word. The DEV_ device exists, it shouldn't be hard to adapt. But basically it's a separate project, if there was a thing it would simply just use the thing, too. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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 directory (ie file type 255). I'm not sure I fully understand what you mean, but here goes: Using your example above, in BASIC using FNAME$ you can extract the filename part to separate it from the directory name - I do this in Q-Trans. channel=FOP_DIR(win1_basic_exts_turbo_config_exe) PRINT FNAME$(#channel) CLOSE #channel FNAME$ on a channel opened by FOP_DIR returns the pure directory name. Assuming your program int he example is called turbo_config_exe, FNAME$ would in this case return basic_exts, the directory in which turbo_config_exe is called. The above is from memory and I think only works if you use FOP_DIR (i.e. it has to be open directory channel). I think in this situation that FNAME$ returns the directory name and not the pure filename, but is easily checked. All I'm saying is that (assuming I understood the message first time) it is possible to some extent already. -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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. This could now be the pointer to the directory string (alternative registers could be used instead, if better). I prefer this type of approach as it would ensure that the home directory (or whatever) would be removed together with the job. However, I perceive several problems with this approach: 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 Not at all. Currently (a6,a5) points to the top of the data area. That doesnt change! Only cognizant programs would attempt to peek beyond their area into the void. There, if they were EXecuted by an equally cognizant OS, they would find a marker that tells them that there is a HD there. If the OS were not HD-aware the program would have to offer a warning to the user or find some workaround. Non-HD-aware programs would not even look. Ie this method would be wholly transparant to legacy programs. 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 The OS already provides that information unambiguously. In S*basic try: ch = FOP_IN(path+name): PRINT FNAME$(#ch): CLOSE#ch ch = FOP_DIR(path+name): PRINT FNAME$(#ch): CLOSE#ch Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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 completely made up my mind yet. Theres no stack hack involved; simply a new convention. I suspect you may have the path depth/filename length issue at the back of your mind. So did I. Ideally, setting up the stack in this way should be done via a single system call (a System Service call in my parlance), accessable to any program or toolkit that is in the business of EXecuting jobs for whatever reason. That way, if at some time in the future the 36 char limit were to be removed, there would only be a single routine to change. M/c programs wanting to set up sub-jobs for it own purposes could still do so manually in the old way, ignoring the new convention if it doesnt need HDs. My proposal is less likely to fragment memory and would use less of it (M/c programs could simply use the memory reserved for the HD if it were not required). 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. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] I'm home, dear.
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. 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 Simple. Open_dir win1_basic_exts_turbo_config_exe. Get the name of the resulting file. This will be the directory name (!). (...) Wolfgang -- W. H. Lenerz www.scp-paulet-lenerz.com -- ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
