"Faking" a WPTransient derived object to appear as a "WPDataFile" derived object - possible ?
Lars Erdmann
a question to the experts (Rich Walsh maybe ?):
I am writing a PAM (project access method) for VAC Version 3 IWF
(integrated workframe). A PAM abstracts access to what IBM calls "parts"
that are part of a "container". For an ordinary filesystem, a "part" is
a file and a "container" is a directory.
The PAM I want to implement is to support ZIP Files. The general idea is
to provide a ZIP file viewer through IWF. The solution is to treat the
ZIP file as a "container" and the contained "parts" as files.
When the PAM interface lists "containers" and their contained "parts" in
a project, it has 2 alternative ways of dealing with "containers" and
"parts":
a.) through a "file" interface function. For the "parts", that function
expects to be passed a number of structures that basically are
FILEFINDBUF3 structures (with a few extensions)
b.) through an "object" interface function. For the "parts", that
function expects to be passed a number of pointers to WPFileSystem or
WPFileSystem derived objects
In fact I have already written that PAM with the a.) interface and it
works well (it even supports all actions that are defined for a
project). I have just "faked" correct contents of the FILEFINDBUF3
structure to correctly represent the files in the ZIP file. However, for
various reasons I want to rewrite this thing to use b.)
However, the ZIP file is not a real directory and the contained files
are not real files in the filesystem. However, if IWF DLLs call the PAM
through interface b.) (info: if b.) is not exported a.) is used and
that's what I did up to now) they expect to be passed WPFileSystem or
derived objects for b.) as this info is later used to construct "real"
commandlines when an action is fired upon a "part" (opening with editor,
running compiler against it, etc.).
My idea is now to create WPTransient derived objects for the files
contained in the zip file. I have a fairly good idea of what WPS methods
will be called, most likely: wpQueryTitle, wpQueryRealName,
wpQueryFilename,wpQueryDateInfo etc.
Q1: if I create a WPTransient derived class that also defines these
methods with the exact same names, will these methods then be proplerly
called ? In other words, does SOM resolve static methods by names or by
their fixed method pointer location in the method table ? If the latter,
can I somehow circumvent this to use lookup by name or make sure that
the method table has these methods at the very same location in the
method table ?
Q2: when is a WPTransient derived object deleted ? I know at what point
to create these WPTransient derived objects but I don't have a
good/proper place to delete them.
Thanks for any help,
Lars
ML
> b.) through an "object" interface function.
ZIP IFS (just hoping... :-))?
---
Lars Erdmann
> > b.) through an "object" interface function.
>
> ZIP IFS (just hoping... :-))?
>
>
>
> ---
can be such a thing as a ZIP IFS. an IFS implements all the low level
volume+file+directory access/manipulation/management functions that are
called by the kernel (DosCopy,
DosDelete,DosFindFirst,DosFindNext,DosFindClose etc. and things beyond
that) . It cannot know if something is a real file or not, it always
assumes something to physically exist.
What WOULD be possible is to write a WPS class that has some special
handling for ZIP files (for example showing its contents and allow the
usual copy/move/delete manipulations).
Lars
Ruediger Ihle
> I haven't thought this through the whole way, but I don't think there
> can be such a thing as a ZIP IFS. an IFS implements all the low level
> volume+file+directory access/manipulation/management functions that are
> called by the kernel (DosCopy,
> DosDelete,DosFindFirst,DosFindNext,DosFindClose etc. and things beyond
> that) . It cannot know if something is a real file or not, it always
> assumes something to physically exist.
ISTR, that there was an article on EDM discussing an IFS
implmentation, that basically forwards all requests to a
R3 deamon. AFAIK, this is the way NetDrive and it's plugins
are working and I don't see why it shouldn't be possible to
use this mechanism to access ZIP files as well. However, I'm
not sure if this is what you want...
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Please remove all characters left of the "R" in my email address
Rich Walsh
> The PAM I want to implement is to support ZIP Files. The general idea is
> to provide a ZIP file viewer through IWF. The solution is to treat the
> ZIP file as a "container" and the contained "parts" as files.
[...]
> b.) through an "object" interface function. For the "parts", that
> function expects to be passed a number of pointers to WPFileSystem or
> WPFileSystem derived objects
[...]
> My idea is now to create WPTransient derived objects for the files
> contained in the zip file.
This sounds like a more ambitious version Object Desktop's ZipFolder class
(TSZipMgr). When this file object is opened, a container is populated
with WPTransient-derived objects (TSZipElem) which represent each file
in the zip (the objects themselves are hidden away in a subdirectory
named "ziptemp"). Actions that require an actual file (e.g. opening
it) cause the file to be extracted to "ziptemp". The appropriate
method is then called on the file object.
> if IWF DLLs call the PAM [...] they expect to be passed WPFileSystem or
> derived objects [...] I have a fairly good idea of what WPS methods
> will be called, most likely: wpQueryTitle, wpQueryRealName,
> wpQueryFilename,wpQueryDateInfo etc.
>
> Q1: if I create a WPTransient derived class that also defines these
> methods with the exact same names, will these methods then be proplerly
> called ? In other words, does SOM resolve static methods by names or by
> their fixed method pointer location in the method table ? If the latter,
> can I somehow circumvent this to use lookup by name or make sure that
> the method table has these methods at the very same location in the
> method table ?
Take a look at wppgm.idl & wppgmf.idl. You'll see both define new methods
that have the same name (e.g. wpQueryProgDetails) and both qualify them
with the keyword "namelookup". E.g. wpQueryProgDetails: namelookup;
If this works at all, doing something similar with methods like
wpQueryRealName that return meta-data shouldn't be too hard. However,
identifying what call(s) should trigger the creation of a real file
may prove more challenging.
--
== == almost usable email address: Rich AT E-vertise.Com == ==
___________________________________________________________________
|
| DragText v3.9 with NLS support
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://e-vertise.com/dragtext/
___________________________________________________________________
ML
>> It cannot know if something is a real file or not
think of a single reason why I cannot assign drive letter(s) to ZIP
file(s). It can contain EAs, files, directories, other ZIP files, be
read-only, limited in capacity, and so on. Just like any other "drive"
(/tapes/RAM/parked cars/images/paper-with-holes/disks/...).
>> it always assumes something to physically exist.
I'ld prefer "ZIP.IFS always pretends something to physically exist". As
long as it e.g. shouldn't return an understandable SYS0002, obviously.
Z(ip): should then behave the same way as A(floppy):, C(harddisk): or
S(DVD-ROM):. Just like my SCREEN$ (or SPEAKER$) can be my PRINTER$,
basicly: all are devices with the same relevant output properties
> ISTR, that there was an article on EDM discussing an IFS
> implmentation
I don't know that's available, and was mainly thinking about a generic
solution. There may be differences indeed, e.g. using a folder concept
instead of a drive-based solution. But that wasn't a requirement, while
a drive-based solution already should work with all basic "objects". A
ZIP file can become a WPDrive, and anything in the ZIP file should be
representable as the matching original "object" (WPFolder, ...).
> NetDrive
Good example. FTP-PM signals transfer errors NetDrive doesn't notice,
but that's most likely a NetDrive-related bug, and I didn't use a "/V"
with my plain COPY operation from C: to F: (being ftp.myisp.net/mydir,
using NDFS.IFS to pretend F: represents a regular OS/2 drive object).
---
Paul Ratcliffe
> Who cares? The device driver (/OS) should take care of that! I cannot
> think of a single reason why I cannot assign drive letter(s) to ZIP
> file(s).
Because it is grossly inefficient and difficult to do so. The ZIP format
was not designed to be a random access read/write container. That's why
you don't format your disk partitions as ZIP but use FAT, HPFS, JFS, NTFS
etc. which were designed with this in mind.
The same applies to ISO. I maintain ISOFS which is an IFS that allows
a drive to be mapped to a .ISO file and gives direct access to the contents.
I have been asked for write access, but it is very diffcult to implement as
the container format was not designed to allow it to be used in this way.
It is most definitely a single sequential write type of FS.
It is relatively easy to allow random read access however.
ML
>> I cannot think of a single reason why I cannot assign drive
>> letter(s) to ZIP file(s).
> Because it is grossly inefficient and difficult to do so.
Sure! I'm not advocating DoubleSpace, nor optimization possibilities
(including risky ones). There are a few other ZIP-specific issues to
care about, I'ld say.
But OTOH you can use a ZIP IFS, without having to use it. Anyway, it
should use the proper WPS objects in this case, and I can think of a
few other purposes too (often trading some speed for ease-of-use,
and there may be an awful lot to trade).
I've got nothing to add nor say about "difficult", not having written
a ZIP IFS ever, and I wasn't meeting any requirements related to any
level of ease. You may be right or wrong about difficult, I really
don't know.
> FAT, HPFS, JFS, NTFS
Slightly different league? I'ld likely only use a ZIP IFS-option if I'ld
also be fine with using an USB 1.0 memory device to store the files on.
Right now I've about 9 smaller archived files, parts of backups yet to
be processed. Compiling those already takes some time. I wouldn't mind
being able to call that my Z:-drive. I also have 5 larger files, which
I don't want to grow file-by-file. About the same may apply to ISO. I
think a typical ISO image is rather large on an USB 1.0-scale, while a
ZIP file isn't. Your initials here: PR. R*.ZIP in my download directory
are 105 files, average size 348.4 KB. That's workable with USB 1.0, in
a 5"25 range too. The average for P*.ZIP is 115.7 KB. I assume typical
ISO files are far larger than those averages. That means I certainly
could pick a ZIP IFS tool for some jobs, while also being aware of your
understandable, efficiency-related remark.
---
ML
> I maintain ISOFS which is an IFS that allows
There's some space to remain in control here: disallow huge sizes
or change ratio's. Change a bit in a 634 MB ISO file: no, sorry.
Replace all 4 files in a 634 KB ZIP file: proceed, the author of
the ZIP IFS doesn't expect a lot of speed-related complaints. Or
warn, sometimes also an option. FWIW.
---
Peter Flass
I don't know IFS's either, but how would you "mount" the zip file? I
guess you could do it the same way the system handles USB devices.
Bob Eager
wrote:
> I don't know IFS's either, but how would you "mount" the zip file? I
> guess you could do it the same way the system handles USB devices.
Easy enough....it's been done in the MAPISO driver/etc. and in others.
Pretty standard technique; I've been using it since the mid 1980s on
various systems!
Dave Yeo
> The PAM I want to implement is to support ZIP Files.
Came across this, http://zziplib.sourceforge.net/ and thought of this
thread.
Dave
Paul Ratcliffe
> But OTOH you can use a ZIP IFS, without having to use it.
What in the world are you on about? This is completely non-sensical.
> I'ld likely only use a ZIP IFS-option if I'ld also be fine with using
> an USB 1.0 memory device to store the files on.
An IFS can't dictate this. You have to support the worst case scenario.
> Right now I've about 9 smaller archived files, parts of backups yet to
> be processed. Compiling those already takes some time. I wouldn't mind
> being able to call that my Z:-drive. I also have 5 larger files, which
> I don't want to grow file-by-file. About the same may apply to ISO. I
> think a typical ISO image is rather large on an USB 1.0-scale, while a
> ZIP file isn't.
I don't know what USB 1.0 has got to do with anything relating to this.
A (conventional) ZIP file can be any size up to 2GB.
> Your initials here: PR. R*.ZIP in my download directory
> are 105 files, average size 348.4 KB. That's workable with USB 1.0, in
> a 5"25 range too. The average for P*.ZIP is 115.7 KB. I assume typical
> ISO files are far larger than those averages. That means I certainly
> could pick a ZIP IFS tool for some jobs, while also being aware of your
> understandable, efficiency-related remark.
I don't know what you're rambling about.
Paul Ratcliffe
> > I maintain ISOFS which is an IFS that allows
>
> There's some space to remain in control here: disallow huge sizes
> or change ratio's. Change a bit in a 634 MB ISO file: no, sorry.
Changing a bit is not a problem in an ISO file. Extending a file probably is.
In the worst case you'd have to rewrite the entire ISO and make sure the
working space is available to do so.
> Replace all 4 files in a 634 KB ZIP file: proceed, the author of
> the ZIP IFS doesn't expect a lot of speed-related complaints. Or
> warn, sometimes also an option. FWIW.
But the IFS doesn't know what the application writer is going to do
with the files. It cannot dictate what it is and isn't going to handle.
It doesn't have the bigger picture to be able to decide.
Frankly, you have no idea what you are talking about.
Paul Ratcliffe
> I don't know IFS's either, but how would you "mount" the zip file? I
> guess you could do it the same way the system handles USB devices.
That's the easy bit. You could do it like ISOFS does it:
mapiso x: c:\test.iso
mapzip x: c:\test.zip
All in all, it's hugely cumbersome and no-one in their right mind would
implement such an IFS.
Ilya Zakharevich
> On Sat, 23 May 2009 10:38:37 +0200, ML <spam...@hotmai1.com> wrote:
>
>> Who cares? The device driver (/OS) should take care of that! I cannot
>> think of a single reason why I cannot assign drive letter(s) to ZIP
>> file(s).
>
> Because it is grossly inefficient
Sometimes... I think sequential access is much more typical...
> and difficult to do so.
RO is trivial... My Perl module implementing RO access has about 100
LOC (the intent is to support small files - to use ActiveState's Perl
distributions without unzipping; but with a handful more lines an
effecient sequential access could be implemented too).
> The ZIP format was not designed to be a random access read/write
> container.
Who cares? If what caller NEEDs is to access ZIP as an IFS with
random access, the inefficiencies become user's problems.
> The same applies to ISO. I maintain ISOFS which is an IFS that allows
> a drive to be mapped to a .ISO file and gives direct access to the contents.
> I have been asked for write access, but it is very diffcult to implement as
> the container format was not designed to allow it to be used in this way.
Not fully true, with multisession... And quite easier to do when the
caller provides a correct file size. (I wonder how often the correct
size is implemented in OS/2 programs; I doubt it is typical...)
Hope this helps,
Ilya
ML
> If what caller NEEDs is to access ZIP as an IFS with random access,
> the inefficiencies become user's problems.
possible to copy (actually: add, one-by-one) a lot of tiny files to an
existing ZIP file. Apart from a possible improvement ("cache" methods),
I think such a problem happens to you only once.
From then on you ought to be aware of the problem, and should know
which tool to use best for a specific task.
This tool also can protect the mailbox of the author of this tool, and
the user, if really needed. The problem, if any (it's your choice of
tools), is predictable, and a (ARJ/LZH/RAR/...-) ZIP IFS replaces no
other option. I'll be just an extra tool, which can be used. Or not.
Just like NetDrive, including a possible FTP performance "problem".
---
ML
> how would you "mount" the zip file?
One can auto-assign a (range of) drives to it, RMB, associate it with
a MOUNT.EXE, start PMMOUNT.EXE manually, ... Maybe by default you can
even still open it with e.g. WarpZIP, but also assign a drive to the
ZIP file.
I think it's a tool. I don't think there's any need to always "mount"
all ZIP files, regardless of the other IFS in use.
---
ML
> You could do it like ISOFS does it:
> no-one in their right mind would implement such an IFS.
Agreed! :-)
---
Lars Erdmann
1.) Prob is, I can only specify "namelookup" for my WPTransient derived
class. But WPFileSystem/WPDataFile classes are already defined to be
"static" so I cannot achive the same as with WPProgam/WPProgramFile classes.
2.) Calls that need a "real" file are not a problem to determine. The
PAM has a different entry point for actions called on files. When this
entry point is called, I know the PAM needs real files to do its job. It
even passes a commandline that is a "real" commandline for a tool
invocation to do something with a "real" file. In short: entry point
"WkfQueryFiles" exists to query the "parts" in a container and you can
either fake files or file objects. "WkfRun" (and "WkfCopyFile",
"WkfDelete") is called with being passed a "real" commandline that
depends on what info has been passed on "WkfQueryFiles" (in particular:
filenames and directory names).
Lars
Lars Erdmann
(rather: a filesystem)" that is to be handled by a ZIP IFS. It's not an
automatism (by the way: what's the DOS API to do that ?).
And: how do you then unmount this ZIP file from the IFS that originally
handles the filesystem the ZIP file is physically "located in" ? Or is
this not necessary (peaceful coexistance ?) ?
Lars
Peter Flass
> > If what caller NEEDs is to access ZIP as an IFS with random access,
> > the inefficiencies become user's problems.
>
> AFAICT WinXP has an ugly-mode ZIP-folder implementation, and it's then
> possible to copy (actually: add, one-by-one) a lot of tiny files to an
> existing ZIP file. Apart from a possible improvement ("cache" methods),
> I think such a problem happens to you only once.
I've gotten used to XP's implementation. It's not necessarily so ugly,
but, like all win-stuff, it's half-assed. Bill never figured out how to
use drag-n-drop properly.
ML
> It's not an automatism
it as a folder. That's why I was thinking about drives (independency)
instead of a folder approach; I will be surprised if you can do that
without also modifying e.g. HPFS.IFS.
The level of automatism further depends on the implementation. If it's
possible, I'll still be using WarpZIP by default, and DosFSAttach() as
a non-default RMB "open" option.
> Or is this not necessary (peaceful coexistance ?) ?
Unlike with SUBST, you'll probably want to keep peace if Z: is actually
used. I won't use both. It's very unlikely I'll be copying files to Z:,
while actually using WarpZIP to view this C:\MY.ZIP.
---
ML
> I've gotten used to XP's implementation.
tools for those situations (just like you'll won't install a database
on an USB 1.0 drive in a ZIP IFS-controlled file structure).
> it's half-assed.
And, AFAIK, e.g. adds files one-by-one, while it's not required at all
to actually update the whole ZIP file each time. A few optimizations
are possible, caching-related, albeit that increases the level of IFS-
difficulty.
---
A.D. Fundum
> ISTR, that there was an article on EDM discussing an IFS
> implmentation
http://www.edm2.com/0103/os2ifs1.html (part 1 of 3)
---
Rich Walsh
> 1.) Prob is, I can only specify "namelookup" for my WPTransient derived
> class. But WPFileSystem/WPDataFile classes are already defined to be
> "static" so I cannot achive the same as with WPProgam/WPProgramFile classes.
That's not a problem - you don't need name lookup for real files, only
for your WPTransient look-alikes.
> 2.) Calls that need a "real" file are not a problem to determine. The
> PAM has a different entry point for actions called on files. When this
> entry point is called, I know the PAM needs real files to do its job. It
> even passes a commandline that is a "real" commandline for a tool
> invocation to do something with a "real" file. In short: entry point
> "WkfQueryFiles" exists to query the "parts" in a container and you can
> either fake files or file objects. "WkfRun" (and "WkfCopyFile",
> "WkfDelete") is called with being passed a "real" commandline that
> depends on what info has been passed on "WkfQueryFiles" (in particular:
> filenames and directory names).
If the methods that require real files pass you either object pointers
or f/q paths that you can correlate to your fake file objects, then it
all sounds pretty easy.
Paul Ratcliffe
> Ok, but that also means that it becomes a USER action to mount a "file
> (rather: a filesystem)" that is to be handled by a ZIP IFS. It's not an
> automatism (by the way: what's the DOS API to do that ?).
DosFSAttach()
> And: how do you then unmount this ZIP file from the IFS that originally
> handles the filesystem the ZIP file is physically "located in" ? Or is
> this not necessary (peaceful coexistance ?) ?
You don't (and indeed can't). You just open it for deny read and deny write
access to anyone else.
Lars Erdmann
"Rich Walsh" <spamyo...@127.0.0.1> schrieb im Newsbeitrag
news:brddYgxvE0gm-pn2-dHMsVci2fOCz@localhost...
> On Sun, 24 May 2009 10:51:22 UTC, Lars Erdmann <lars.e...@arcor.de>
> wrote:
>
>> 1.) Prob is, I can only specify "namelookup" for my WPTransient derived
>> class. But WPFileSystem/WPDataFile classes are already defined to be
>> "static" so I cannot achive the same as with WPProgam/WPProgramFile
>> classes.
>
> That's not a problem - you don't need name lookup for real files, only
> for your WPTransient look-alikes.
Ah, so I understand that SOM will figure out itself that when it calls into
my WPTransient derived objects that it HAS to and WILL use namelookup even
though it does not know beforehand of what SOM class the object will be but
will find out during runtime. That sounds promising.
>
>> 2.) Calls that need a "real" file are not a problem to determine. The
>> PAM has a different entry point for actions called on files. When this
>> entry point is called, I know the PAM needs real files to do its job. It
>> even passes a commandline that is a "real" commandline for a tool
>> invocation to do something with a "real" file. In short: entry point
>> "WkfQueryFiles" exists to query the "parts" in a container and you can
>> either fake files or file objects. "WkfRun" (and "WkfCopyFile",
>> "WkfDelete") is called with being passed a "real" commandline that
>> depends on what info has been passed on "WkfQueryFiles" (in particular:
>> filenames and directory names).
>
> If the methods that require real files pass you either object pointers
> or f/q paths that you can correlate to your fake file objects, then it
> all sounds pretty easy.
Not quite. The PAM design is really shitty in the way that on invoking an
action (calling a tool on a file/directory) via WkfRun, the calling IWF DLL
has already preconstructed the commandline. And that's exactly the problem:
if I support the "file" interface on WkfQueryFiles instead of the "object"
interface, IWF slightly screws up on constructing the commandline and I had
to work around the problem which still leaves me with a suboptimal solution.
Supporting the "object" interface on WkfQueryFiles I hope that the screw up
does not happen and therefore no workaround will be necessary.
Lars