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