ISOFS - OS2

This is a discussion on ISOFS - OS2 ; On Tue, 07 Dec 2004 10:19:20 -0500, David Graser wrote: > eCS 1.2 comes with a program called Removable Drive Monitor found in the > system's startup folder. It monitors for any insertion of USB devices. Yuck. Another nasty program. ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 42

Thread: ISOFS

  1. Re: ISOFS

    On Tue, 07 Dec 2004 10:19:20 -0500, David Graser wrote:

    > eCS 1.2 comes with a program called Removable Drive Monitor found in the
    > system's startup folder. It monitors for any insertion of USB devices.


    Yuck. Another nasty program. Why create an entry in the task list and
    a window which displays nothing but white? Why make it PM in the first
    place?
    Luckily, I've analyzed how it works :-)

    > As for drive letters, you can assign the drive a premanent drive letter
    > using LVM. That is what I have done with all my removable media.
    > Otherwise, the system always chooses the drive letter.


    Even on removable media? My CF card is FAT formatted and has no partitions,
    being essentially a large floppy. So where does the LVM info. get stored?
    I guess I'll have to try it.

  2. Re: ISOFS

    On Tue, 7 Dec 2004 21:12:43 +0000 (UTC), Ilya Zakharevich
    wrote:

    >> It has fixed the horrid bugs, but the code's even more of a mess now a
    >> couple more features have been bolted on.

    >
    > Coding styles may be very different for different people...


    This is not a matter of style. It is just plain bad programming practice.

    > a) it would not strip trailing ";1" from Joliet names (I recognized
    > that ISOFS has this problem after reading
    > http://arost.redirectme.net/sw/mkisofs/ yesterday).


    I haven't found an image where this happens, but then I've only tested
    it on 3 or 4. You will have to test it, as and when.

    > b) It would be great if it recognized file names like v: or ac:, and


    I have absolutely no idea what this means.

    > open them with OPEN_FLAGS_DASD flag, and do the necessary locking
    > via DosDevIOCtl, Category 8, DSK_LOCKDRIVE. (Or do the similar
    > thing for filenames \\.\v: or \\.\ac: - I think that contrary to
    > examples OPEN_ACCESS_READONLY does not work for these files).


    What on Earth would you want to open the drive in DASD mode for?
    If you want to do that, just open the original .iso file instead. It'll be
    a damned sight quicker as well, without all the IFS and daemon overheads
    and dozens of context switches.

  3. Re: ISOFS

    On 7 Dec 2004 08:04:54 GMT, Bob Eager wrote:

    > On Tue, 7 Dec 2004 00:38:50 UTC, Paul Ratcliffe
    > wrote:
    >
    >> > P.S. Would not it be easier to implement images the other way around:
    >> > by associating a drive letter with a file via some DMD, then let the
    >> > standard OS/2 mechanism recognize that the FS is ISO one?

    >>
    >> I've no idea. Never written a DMD before. I'm not quite sure how you'd
    >> associate drives with files anyway. An IFS is much easier, especially
    >> as it's already written.

    >
    > Yes, I'd be tempted to go right down to the lowest level, and make a
    > 'pseudocdrom.sys' driver. That could then connect to the file, and also


    Then you'd be stuck with reserving drive letters. I don't know about
    you, but I'm running out and I don't want to dedicate them to things
    that are dynamically assigned. You lose all your flexibility.

    > attach to the CDROM FSD. No need to understand any file formats then...


    ..ISO is not that difficult really. Does CDROM support such an attachment
    and how would you do it?
    It doesn't give you any scope to work round problems or limitations in
    the FSD either, such as the one Ilya was talking about with XP. I guess
    OS/2 can't cope with that buglet.

  4. Re: ISOFS

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Paul Ratcliffe
    ], who wrote in article :
    > > a) it would not strip trailing ";1" from Joliet names (I recognized
    > > that ISOFS has this problem after reading
    > > http://arost.redirectme.net/sw/mkisofs/ yesterday).

    >
    > I haven't found an image where this happens


    As the URL claims, this is the default for disks created under Windows.

    > > b) It would be great if it recognized file names like v: or ac:, and

    >
    > I have absolutely no idea what this means.


    You have a CD; cddrive is in v:. You insert CD in the drive, and do

    mntisofs --charset=cp819 v: z:

    with the proposal I gave you get the CD mounted on z: with the given
    charset translation. Currently you need to make an ISO image to read
    files from a CD which have "unreadable" names.

    Hope this helps,
    Ilya

  5. Re: ISOFS

    On Fri, 10 Dec 2004 00:29:38 UTC, Paul Ratcliffe
    wrote:

    > > Yes, I'd be tempted to go right down to the lowest level, and make a
    > > 'pseudocdrom.sys' driver. That could then connect to the file, and also

    >
    > Then you'd be stuck with reserving drive letters. I don't know about
    > you, but I'm running out and I don't want to dedicate them to things
    > that are dynamically assigned. You lose all your flexibility.


    Not really. I was thinking of a 'mount' system. So you'd run a program
    to attach a file to a drive letter, equivalent to inserting a CD. Same
    number of drive letters (usually one) required.

    > > attach to the CDROM FSD. No need to understand any file formats then...

    >
    > .ISO is not that difficult really. Does CDROM support such an attachment
    > and how would you do it?


    I haven't looked at precise details, but attachment of what would appear
    to be a hardware device would be no different to dynamic attachment of a
    real hardware device (AFAICS).

    > It doesn't give you any scope to work round problems or limitations in
    > the FSD either, such as the one Ilya was talking about with XP. I guess
    > OS/2 can't cope with that buglet.


    That is true.

  6. Re: ISOFS

    On Fri, 10 Dec 2004 03:05:41 +0000 (UTC), Ilya Zakharevich
    wrote:

    > You have a CD; cddrive is in v:. You insert CD in the drive, and do
    >
    > mntisofs --charset=cp819 v: z:
    >
    > with the proposal I gave you get the CD mounted on z: with the given
    > charset translation. Currently you need to make an ISO image to read
    > files from a CD which have "unreadable" names.


    Ah, now I see what you mean. I've never thought of using the raw file
    system APIs before, but they do an absolutely cracking job.
    I just wrote a very simple program to copy an ISO from a CD to a file.
    It works just like any other file copying program. Brilliant!
    (Of course, stupid cmd.exe interprets \\.\J: as a network path, which is
    why I had to do my own copy program.)

    At the moment, there is code in isofsdmn to stop you mounting some things
    starting with \\, but I think it's a needless restriction.
    Unfortunately, the C libraray doesn't seem to support "\\.\x:" on fopen()
    so I'll need to make that use native API calls.
    Then, what you want should just happen, aside from cp819 not being a
    supported codepage of course.

  7. Re: ISOFS

    On 10 Dec 2004 07:42:58 GMT, Bob Eager wrote:

    >> > Yes, I'd be tempted to go right down to the lowest level, and make a
    >> > 'pseudocdrom.sys' driver. That could then connect to the file, and also

    >>
    >> Then you'd be stuck with reserving drive letters. I don't know about
    >> you, but I'm running out and I don't want to dedicate them to things
    >> that are dynamically assigned. You lose all your flexibility.

    >
    > Not really. I was thinking of a 'mount' system. So you'd run a program
    > to attach a file to a drive letter, equivalent to inserting a CD. Same
    > number of drive letters (usually one) required.


    That's how it works now with an IFS. You can attach as many images to
    as many drive letters as you like.

    > I haven't looked at precise details, but attachment of what would appear
    > to be a hardware device would be no different to dynamic attachment of a
    > real hardware device (AFAICS).


    And how do you do the latter?

  8. Re: ISOFS

    On Fri, 10 Dec 2004 14:53:44 UTC, Paul Ratcliffe
    wrote:

    > That's how it works now with an IFS. You can attach as many images to
    > as many drive letters as you like.


    Exactly. What I mean is that you don't need one letter for every ISO
    image; you attach and detach, akin to inserting/removing CDs. So it
    would only use one drive letter if you were short of them.

    > > I haven't looked at precise details, but attachment of what would appear
    > > to be a hardware device would be no different to dynamic attachment of a
    > > real hardware device (AFAICS).

    >
    > And how do you do the latter?


    Same as for USB devices, I guess. Once you can get a (pseudo) hardware
    device driver to give block access to the ISO image file, that is, and
    the latter is not particularly difficult.


  9. Re: ISOFS

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Paul Ratcliffe
    ], who wrote in article :
    > > You have a CD; cddrive is in v:. You insert CD in the drive, and do
    > >
    > > mntisofs --charset=cp819 v: z:
    > >
    > > with the proposal I gave you get the CD mounted on z: with the given
    > > charset translation. Currently you need to make an ISO image to read
    > > files from a CD which have "unreadable" names.

    >
    > Ah, now I see what you mean.


    Actually, 90% of time I use ISOFS is to read CDs which are not
    readable by OS/2's CDFS.IFS (broken Joliet, or duplicate file names
    after `to-"_" translation', or some other problems). It is very rare
    that I have an ISO image which is not done by myself.

    Thanks,
    Ilya

  10. Re: ISOFS

    Paul Ratcliffe wrote:

    > Even on removable media? My CF card is FAT formatted and has no partitions,
    > being essentially a large floppy. So where does the LVM info. get stored?
    > I guess I'll have to try it.


    Paul

    It is my understanding that LVM stores drive letter information in an
    unused portion of the Master Boot Record of the drive.

    David

  11. Re: ISOFS

    On Sat, 11 Dec 2004 04:09:17 UTC, David Graser
    wrote:

    > Paul Ratcliffe wrote:
    >
    > > Even on removable media? My CF card is FAT formatted and has no partitions,
    > > being essentially a large floppy. So where does the LVM info. get stored?
    > > I guess I'll have to try it.

    >
    > Paul
    >
    > It is my understanding that LVM stores drive letter information in an
    > unused portion of the Master Boot Record of the drive.


    No. The first lot is in a spare sector on the first track. Others are in
    similar places across the drive.


  12. Re: ISOFS

    David Graser wrote:

    > It is my understanding that LVM stores drive letter information in an
    > unused portion of the Master Boot Record of the drive.


    No, it is stored in an area befor the actual partition/volume.
    That is the reason for problems when there is no space because
    of superfloppy formats, and unusual geometries.

    Abstracted typical harddisk:

    Track 0...... Track 1...
    |Mbr| empty... | LVM info| Partition 1

    The LVM sector is in the same track as
    the partition table/extended partition table setor,
    but in the last sector of this track.
    Current harddisk usually offer 63 sectors per track
    in the translated geometry, so it will end up in sector 63.

    --
    Veit Kannegieser

  13. Re: ISOFS

    Paul Ratcliffe wrote:

    > Unfortunately, the C libraray doesn't seem to support "\\.\x:" on fopen()
    > so I'll need to make that use native API calls.


    Cant you simply use "x:" as well?
    But then the open_flags_Dasd would be needed.

    --
    Veit Kannegieser

  14. Re: ISOFS

    On 11 Dec 2004 13:54:51 GMT, Veit Kannegieser
    wrote:

    > Paul Ratcliffe wrote:
    >
    >> Unfortunately, the C libraray doesn't seem to support "\\.\x:" on fopen()
    >> so I'll need to make that use native API calls.

    >
    > Cant you simply use "x:" as well?
    > But then the open_flags_Dasd would be needed.


    But that would stop anything else getting at the drive and require it
    to be locked for exclusive use. The raw file system APIs do not require
    this.
    I also found out that for raw file system access:
    fopen() doesn't work on GCC or VAC
    open() works on VAC, but not GCC
    _abspath() on GCC turns "\\.\X:" into "\\X:"

    So I stripped all that out and went with DosOpen() which works fine.
    Now I just need to find out how to get GCC to do what I want.
    I have managed to get it to link statically, but the EXEs are absolutely
    vast compared to an equivalent app. on VAC - 300k compared to maybe 50k
    - not that the ISOFS stuff compiles on VAC, otherwise I'd have used it.

  15. Re: ISOFS

    On Sat, 11 Dec 2004 20:01:05 UTC, Paul Ratcliffe wrote:

    > I have managed to get it to link statically, but the EXEs are absolutely
    > vast compared to an equivalent app. on VAC - 300k compared to maybe 50k
    > - not that the ISOFS stuff compiles on VAC, otherwise I'd have used it.


    Did you try to run lxLite on them? That will break chkdll32 but the size
    shrinks a lot. That's what I did in the version I had compiled for you
    earlier. Well, altogether they were still ~200k...
    --
    Greetings, Please reply in newsgroup, I rarely
    Peter. read emails to pweilba@gwdg.de...

  16. Re: ISOFS

    On 11 Dec 2004 22:45:07 GMT, Peter Weilbacher wrote:

    >> I have managed to get it to link statically, but the EXEs are absolutely
    >> vast compared to an equivalent app. on VAC - 300k compared to maybe 50k
    >> - not that the ISOFS stuff compiles on VAC, otherwise I'd have used it.

    >
    > Did you try to run lxLite on them? That will break chkdll32 but the size
    > shrinks a lot. That's what I did in the version I had compiled for you
    > earlier. Well, altogether they were still ~200k...


    No, but I have now and it takes a bit off. They are still large though.
    Just out of interest, I tried the simplest program:

    main(void)
    {
    return(0);
    }

    With GCC 3.3.5b1 this was nearly 187k. LxLited it becomes 114k.
    With VAC 3.08 this was nearly 19k. LxLited it becomes 12k.

    With dynamic linking things change a bit:
    VAC /Gdm: 2560 => 1255 bytes
    GCC -s: 12292 => 1144 bytes
    GCC -s -Zomf: 1536 => 717 bytes

    But with VAC I can tell it to use OS2OM30.DLL supplied with the operating
    system, whereas GCC needs another 516k DLL.

    What the hell is this thing doing that drags in so much code? It is just
    ridiculous.

  17. Re: ISOFS

    On Sun, 12 Dec 2004 01:11:20 UTC, Paul Ratcliffe wrote:

    > No, but I have now and it takes a bit off. They are still large though.
    > Just out of interest, I tried the simplest program:
    >
    > main(void)
    > {
    > return(0);
    > }
    >
    > With GCC 3.3.5b1 this was nearly 187k. LxLited it becomes 114k.
    > With VAC 3.08 this was nearly 19k. LxLited it becomes 12k.
    >
    > With dynamic linking things change a bit:
    > VAC /Gdm: 2560 => 1255 bytes
    > GCC -s: 12292 => 1144 bytes
    > GCC -s -Zomf: 1536 => 717 bytes
    >
    > But with VAC I can tell it to use OS2OM30.DLL supplied with the operating
    > system, whereas GCC needs another 516k DLL.
    >
    > What the hell is this thing doing that drags in so much code? It is just
    > ridiculous.


    Perhaps it is the early beta status of the GCC version you are using. I
    tried the same experiment with GCC 3.2.2beta4 CSD1, and it gives (in
    bytes, left is raw exe size, right is lxLite'd size)
    GCC 3.2.2 GCC 3.3.5
    gcc 13998 => 2808 14464 => 3322
    gcc -s 12292 => 1098 12292 => 1146
    gcc -Zomf 18366 => 677 18438 => 725
    gcc -Zomf -s 809 => 663 921 => 711
    gcc -Zomf -s -static 61261 => 44246 does not work

    Well, the static executable is still large with 3.2.2 but much less so
    than with 3.3.5. I guess Knut will still optimize that a bit. It is a
    bit strange that I don't get the exact same numbers that you get, and
    that I get
    s:\MozComp\GCC335\lib\libc_s.lib(signals.obj) :
    error LNK2029: "___libc_back_signalOS2V1Handler16bit" :
    unresolved external
    when compiling statically with 3.3.5 and it works for you...
    --
    Greetings, Please reply in newsgroup, I rarely
    Peter. read emails to pweilba@gwdg.de...

  18. Re: ISOFS

    Paul Ratcliffe wrote:

    > On 11 Dec 2004 22:45:07 GMT, Peter Weilbacher wrote:
    >
    >
    >>>I have managed to get it to link statically, but the EXEs are absolutely
    >>>vast compared to an equivalent app. on VAC - 300k compared to maybe 50k
    >>>- not that the ISOFS stuff compiles on VAC, otherwise I'd have used it.

    >>
    >>Did you try to run lxLite on them? That will break chkdll32 but the size
    >>shrinks a lot. That's what I did in the version I had compiled for you
    >>earlier. Well, altogether they were still ~200k...

    >
    >
    > No, but I have now and it takes a bit off. They are still large though.
    > Just out of interest, I tried the simplest program:
    >
    > main(void)
    > {
    > return(0);
    > }
    >
    > With GCC 3.3.5b1 this was nearly 187k. LxLited it becomes 114k.


    Wow! Makes me feel not-so-bad about how my PL/I runtime is progressing.


  19. Re: ISOFS

    On 10 Dec 2004 17:06:09 GMT, Bob Eager wrote:

    >> That's how it works now with an IFS. You can attach as many images to
    >> as many drive letters as you like.

    >
    > Exactly. What I mean is that you don't need one letter for every ISO
    > image; you attach and detach, akin to inserting/removing CDs. So it
    > would only use one drive letter if you were short of them.


    Indeed. But if you want to attach N images at the same time, you could do
    with an IFS, as long as you have N drive letters free. They are created
    and destroyed dynamically.
    With a .SYS, you'd have to reserve N drive letters, whether you want to
    use them all at any one particular time or not, which means they
    wouldn't be available for anything else.

    >> > would be no different to dynamic attachment of a real hardware device

    >>
    >> And how do you do the latter?

    >
    > Same as for USB devices, I guess. Once you can get a (pseudo) hardware
    > device driver to give block access to the ISO image file, that is, and


    It seems odd to use a hardware driver to attach to something that isn't
    hardware. I think the IFS interface is ideal for the task at hand, which
    is probably why it was written like that in the first place.

    I don't see any advantges with a SYS and I see lots of disadvantages.

    > the latter is not particularly difficult.


    I still don't know how.

  20. Re: ISOFS

    On 12 Dec 2004 11:15:22 GMT, Peter Weilbacher wrote:

    > GCC 3.2.2 GCC 3.3.5
    > gcc 13998 => 2808 14464 => 3322
    > gcc -s 12292 => 1098 12292 => 1146
    > gcc -Zomf 18366 => 677 18438 => 725
    > gcc -Zomf -s 809 => 663 921 => 711
    > gcc -Zomf -s -static 61261 => 44246 does not work
    >
    > Well, the static executable is still large with 3.2.2 but much less so
    > than with 3.3.5. I guess Knut will still optimize that a bit.


    Maybe, maybe not. IME, things like this rarely improve. Additional code
    has gone in to support something and it doesn't come out again.

    > that I get
    > s:\MozComp\GCC335\lib\libc_s.lib(signals.obj) :
    > error LNK2029: "___libc_back_signalOS2V1Handler16bit" :
    > unresolved external
    > when compiling statically with 3.3.5 and it works for you...


    No, I get that as well. I had to build using -Zomf -lc_omf386 (having set
    EMXOMFLD_TYPE=VAC308).
    I have no idea what this does as there is no documentation on it that I
    can find. Knut told me to do the above.

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast