EA API oddities - OS2

This is a discussion on EA API oddities - OS2 ; Yo! Now that I've gotten biblically acquainted with these, I thought I'd post a buncha of gotchas I've found working with these, just for future reference. * Names of EAs are supposedly the same character set as HPFS. Well, no. ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: EA API oddities

  1. EA API oddities

    Yo!

    Now that I've gotten biblically acquainted with these, I thought I'd
    post a buncha of gotchas I've found working with these, just for future
    reference.

    * Names of EAs are supposedly the same character set as HPFS. Well, no.
    They are internally converted to uppercase and only support the same
    characters as FAT.

    * EAs are restricted to 64k, right? Nope. There is 2 bytes alloted to
    give the size of the EA (real great future proofing people), but since
    you chain these in a horrid linked-list data structure, each of which
    has its own length information, you can write one of any size and read
    it back. NO checking on the size is done. Found this out the hard way
    when I wrote on the was nearly a a megabyte long. Could read it fine,
    but I have no idea what it might have silently trashed.

    * This ought to be called Amish Assembly Programming, since everything
    is done on the honor system. You can write anything you please (and
    people do, judging by what I've found by snooping around on my hard
    drive). On the one hand, apps should be able to set/manage their own
    EAs, but the format is never checked. A malicious program could easily
    write EAs with conflicting information that would obliterate other apps
    EA data. Oh hey, one version of the IBM Workframe does this....

    * Oh, and the calls to set/get EAs can result in trap 0005 if some
    *undocumented* arguments aren't where they belong. Thank heavens for my
    API book (er, it's got quite a few typos too while we are at it).

    And people wonder why I like Java.... Darn I've gotten good at pointer
    twiddling.

    >

    Jeff


  2. Re: EA API oddities

    spam@jqhome.net schrieb:
    > Yo!
    >
    > Now that I've gotten biblically acquainted with these, I thought I'd
    > post a buncha of gotchas I've found working with these, just for future
    > reference.
    >
    > * Names of EAs are supposedly the same character set as HPFS. Well, no.
    > They are internally converted to uppercase and only support the same
    > characters as FAT.
    >
    > * EAs are restricted to 64k, right? Nope. There is 2 bytes alloted to
    > give the size of the EA (real great future proofing people), but since
    > you chain these in a horrid linked-list data structure, each of which
    > has its own length information, you can write one of any size and read
    > it back. NO checking on the size is done. Found this out the hard way
    > when I wrote on the was nearly a a megabyte long. Could read it fine,
    > but I have no idea what it might have silently trashed.


    The problem is that the API is 32-bit but the IFS's corresponding entry point is plain old 16-bit.
    So I doubt if you will ever be able to read/write more than 64k even though the API call might tell
    you everything was ok.
    In other words, even if the 32-bit API provides 4 bytes to hold the list length,
    the kernel internally thunks this to the old 16-bit structure
    (so FEALIST2 becomes FEALIST and GEALIST2 becomes GEALIST and so on)
    effectively killing the upper 2 bytes of your length.
    It also realigns all the 32-bit EA structures where the elements need to be 4-byte aligned to 2
    bytes alignment.

    >
    > * This ought to be called Amish Assembly Programming, since everything
    > is done on the honor system. You can write anything you please (and
    > people do, judging by what I've found by snooping around on my hard
    > drive). On the one hand, apps should be able to set/manage their own
    > EAs, but the format is never checked. A malicious program could easily
    > write EAs with conflicting information that would obliterate other apps
    > EA data. Oh hey, one version of the IBM Workframe does this....


    There is no security whatsoever regarding EAs. It is just not foreseen.
    And apart from the standard EAs, there is no convention concerning the EA's contents.

    >
    > * Oh, and the calls to set/get EAs can result in trap 0005 if some
    > *undocumented* arguments aren't where they belong. Thank heavens for my
    > API book (er, it's got quite a few typos too while we are at it).
    >
    > And people wonder why I like Java.... Darn I've gotten good at pointer
    > twiddling.

    The API is really sick when you program in C (pointer casting back and forth).
    But in assembly it is quite efficient pointer arithmetic.
    Remember that initially, the IFS's (HPFS.IFS for example) were written in Assembler.
    I guess you will just have to live with that.

    Lars

  3. Re: EA API oddities

    >> And people wonder why I like Java.... Darn I've gotten good at pointer
    >> twiddling.


    I think that, as Lars alluded to elsewhere, this is less an issue of
    Java vs C than anything vs assembly. Further, your comments and
    experience would have been valuable around 1991-1992, or maybe even
    1995, but now OS/2 is pretty much just about gone. You might want to
    invest the effort in Linux.
    -Scott

  4. Re: EA API oddities

    Is the OS/2 API project still limping along on life support? While all
    this is fresh in your mind, it would be a wonderful thing to document it
    all so the next person doesn't have to start from scratch.


    spam@jqhome.net wrote:
    > Yo!
    >
    > Now that I've gotten biblically acquainted with these, I thought I'd
    > post a buncha of gotchas I've found working with these, just for future
    > reference.
    >
    > * Names of EAs are supposedly the same character set as HPFS. Well, no.
    > They are internally converted to uppercase and only support the same
    > characters as FAT.
    >
    > * EAs are restricted to 64k, right? Nope. There is 2 bytes alloted to
    > give the size of the EA (real great future proofing people), but since
    > you chain these in a horrid linked-list data structure, each of which
    > has its own length information, you can write one of any size and read
    > it back. NO checking on the size is done. Found this out the hard way
    > when I wrote on the was nearly a a megabyte long. Could read it fine,
    > but I have no idea what it might have silently trashed.
    >
    > * This ought to be called Amish Assembly Programming, since everything
    > is done on the honor system. You can write anything you please (and
    > people do, judging by what I've found by snooping around on my hard
    > drive). On the one hand, apps should be able to set/manage their own
    > EAs, but the format is never checked. A malicious program could easily
    > write EAs with conflicting information that would obliterate other apps
    > EA data. Oh hey, one version of the IBM Workframe does this....
    >
    > * Oh, and the calls to set/get EAs can result in trap 0005 if some
    > *undocumented* arguments aren't where they belong. Thank heavens for my
    > API book (er, it's got quite a few typos too while we are at it).
    >
    > And people wonder why I like Java.... Darn I've gotten good at pointer
    > twiddling.
    >
    > >
    >
    > Jeff
    >



  5. Re: EA API oddities

    Peter Flass wrote:
    > Is the OS/2 API project still limping along on life support? While all
    > this is fresh in your mind, it would be a wonderful thing to document it
    > all so the next person doesn't have to start from scratch.
    >
    >
    > spam@jqhome.net wrote:
    >



    ---- other stuff removed

    I second that!!! As a learning thing I have been trying to call
    DosQueryPathInfo - FIL_QUERYEASFROMLIST to query a file on a FAT drive
    to check if it has LONGNAME EA and get the LONGNAME. I have found all
    kinds of examples and they are all different. I got "something" to
    work, but what it returns is not what I expected.

    Anyone know a sure way to do the previous?

    --

    M Greene Voice Memeber #1356

    IRC (MikeG): irc.va.webbnet.info #os/2 and #learnc++
    ashburn.va.us.undernet.org #os/2warp irc.ecomstation.com #eCS
    ICQ:319474014 AIM:mikekg2003

    http://members.cox.net/greenemk/os2/index.html

  6. Re: EA API oddities

    Michael Greene wrote:
    > Peter Flass wrote:
    >
    >> Is the OS/2 API project still limping along on life support? While
    >> all this is fresh in your mind, it would be a wonderful thing to
    >> document it all so the next person doesn't have to start from scratch.
    >>
    >>
    >> spam@jqhome.net wrote:
    >>

    >
    >
    > ---- other stuff removed
    >
    > I second that!!! As a learning thing I have been trying to call
    > DosQueryPathInfo - FIL_QUERYEASFROMLIST to query a file on a FAT drive
    > to check if it has LONGNAME EA and get the LONGNAME. I have found all
    > kinds of examples and they are all different. I got "something" to
    > work, but what it returns is not what I expected.
    >
    > Anyone know a sure way to do the previous?
    >


    This is a reference I am using:

    http://www.howzatt.demon.co.uk/articles/06may93.html


    --

    M Greene Voice Memeber #1356

    IRC (MikeG): irc.va.webbnet.info #os/2 and #learnc++
    ashburn.va.us.undernet.org #os/2warp irc.ecomstation.com #eCS
    ICQ:319474014 AIM:mikekg2003

    http://members.cox.net/greenemk/os2/index.html

  7. Re: EA API oddities

    ok, I could send you my ea code. It might help. If you are interested,
    let me have your address. Also, give me a sample of what you are
    getting vs. what you expect. You can look at a file's EAs with

    type -ea:filename > foo.eas

    which pipes them to the foo.eas file.

    *** I AM NO C PROGRAMMER ***

    My stuff is butt-ugly, but it works great so far. If you use it and
    improve it, send it back. I sweated some bullets making this work, so
    it shouldn't get lost.

    Cheers,

    Jeff


  8. Re: EA API oddities

    woops! my almost usable email address is

    jgaynor at jqhome dot net


  9. Re: EA API oddities

    spam@jqhome.net wrote:
    > ok, I could send you my ea code. It might help. If you are interested,
    > let me have your address. Also, give me a sample of what you are
    > getting vs. what you expect. You can look at a file's EAs with
    >
    > type -ea:filename > foo.eas
    >
    > which pipes them to the foo.eas file.
    >
    > *** I AM NO C PROGRAMMER ***
    >
    > My stuff is butt-ugly, but it works great so far. If you use it and
    > improve it, send it back. I sweated some bullets making this work, so
    > it shouldn't get lost.
    >
    > Cheers,
    >
    > Jeff
    >


    Jeff,

    *** I AM NO C PROGRAMMER ***

    But it is fun learning this stuff. The link I posted
    before(http://www.howzatt.demon.co.uk/articles/06may93.html) is very
    good even though dated 1993. Matter of fact, the example program
    compiles with OpenWatcom after adding:

    #define ERROR_USER_DEFINED_BASE 0xF000

    to EAString.h and it works so it is a good example. If you read down a
    bit, the article says this:


    1) Simple data types - which all begin with a 2 byte length then the data:

    EAT_BINARY (binary data), EAT_ASCII (ASCII text),
    EAT_BITMAP (bitmap), EAT_METAFILE (OS/2 metafile),
    EAT_ICON (icon)

    A special case of these is EAT_EA which contains the name of another EA
    containing further data. This provides, among other things, a way
    of generating EA data of more that 64K; which is the limit for a
    single EA data item.

    Which I had not read about before (EAT_EA) and might be a way around the
    64K EA limit.

    Yes, please zip your code and email it - I need every example I can get!

    greenemk@cox.net


    --

    M Greene Voice Memeber #1356

    IRC (MikeG): irc.va.webbnet.info #os/2 and #learnc++
    ashburn.va.us.undernet.org #os/2warp irc.ecomstation.com #eCS
    ICQ:319474014 AIM:mikekg2003

    http://members.cox.net/greenemk/os2/index.html

+ Reply to Thread