Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!ukc!warwick!bsrdp From: bsrdp@warwick.ac.uk (Hylton Boothroyd) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: Execution from archive Summary: looz needs a minor revision Message-ID: <214@orchid.warwick.ac.uk> Date: 5 Aug 89 01:13:50 GMT References: <173@bms-at.UUCP> <6100004@otter.hpl.hp.com> Reply-To: bsrdp@warwick.ac.uk (Hylton Boothroyd) Organization: Warwick Business School Lines: 73 In article <6100004@otter.hpl.hp.com> wnr@otter.hpl.hp.com (Nigel Rea) writes: > Some time ago I came across a program called looz.exe which extracts > small (<64k) programs from ZOO archives and executes them. This is done > completely in memory, so no extra disk space is needed. At present some FOO.COM's, including several MSDOS external commands, do not execute correctly when called from ZOOHIVE.ZOO. A relatively small correction to looz is needed, but until that is made you will need to test programmes individually to see whether they will directly extract and run. I relied on looz working as specified, and re-organized dozens of programmes into ZOO's both to save hard disk space and to avoid long directory listings. Now as I call these programmes up for the first time I find that about 30% of them don't work directly out of a zoo. The clean unified promise has crumbled into a mass of special cases. A problem, possibly *the* problem, is that programmes are offered a parameter string from which the leading white space has been trimmed. [I have a small COM whose sole job is to report what it has been given at PSP:80] If FOO.COM lives as a normal file in a directory, and if you type foo AB then the parameters that arrive in the programme segment prefix at PSP:80 onwards are 80h 81h 82h 83h 03h 20h 41h 42h count space "A" "B" This is where all FOOs find out what they are being asked to do. If FOO.COM lives in a zoo, and if you type the appropriate looz command looz xx zoohive foo AB then the parameters that arrive in the programme segment prefix for foo at PSP:80 onwards are 80h 81h 82h 02h 41h 42h count "A" "B" . No leading space! They are all stripped off! Under MSDOS it couldn't happen like that from the keyboard. It can only happen if a FOO is run by another programme that is too enthusiastic about sanitizing the command string before handing it on. But FOO was designed to cope with what MSDOS could give it. So rather than thinking of my 30% as failing to meet the standard, there is probably some sense in thinking of the 70% as being happily over-designed. Since many MSDOS external commands fall into the 30%, that also seems to be Microsoft's de facto view. Insofar as Rahul relies on C-libraries, he may be cotton-woolled away from direct hands-on management of the data string to preserve it as offered. But he should at least find it trivial to prepend a space to what the library function collects from the PSP, so that the functionality of programmes would be ensured for most normal purposes. As it is, I find it frustrating not to be able to act on my diagnosis. The approach to key instructions in disassembled Pascal and disassembled C is littered with every conceivable generality, so that it is very difficult to be at all sure either what is relevant or what the consequence of change would be. Hylton ----------------------- Hylton Boothroyd Janet: h.boothroyd@uk.ac.warwick.cu Warwick Business School Darpa: h.boothroyd%cu.warwick.ac.uk@relay-nsfnet.ac.uk University of Warwick Uucp: h.boothroyd%sol@warwick.uucp COVENTRY Earn/Bitnet: h.boothroyd%uk.ac.warwick.cu@UKACRL England CV4 7AL Phone: +44 203 523523 Extension 2428 -----------------------