Relationship .BIN/.SO & .EXE/.DLL?

Discussion in 'Java' started by Andrew Thompson, Sep 16, 2006.

  1. I am trying to develop a WebStart launch file for the performance
    pack fo the JMF, similar to the JOGL launch file(1).

    The JOGL webstart supplies native librariess appropriate
    to each platform - .DLL's for Windows, and .SO files for
    the linux/unix boxes (not sure about Mac.).

    The resources section looks like this..
    <resources>
    <jar href="jogl.jar" />
    </resources>
    <resources os="Windows">
    <nativelib href = "jogl-natives-win32.jar" />
    </resources>
    <resources os="SunOS" arch="sparc">
    <nativelib href = "jogl-natives-solsparc.jar" />
    </resources>
    ......

    When it comes to the JMF PP, it is normally supplied in
    an .EXE for Win., which I am guessing installs DLL's, and
    for the Unix/Linux boxes, there is a .BIN file.

    Am I correct in my (wild ass) guess that the crude
    equivalence might be expressed as..
    *nix | .BIN - when run might install .SO
    Win. | .EXE - when run might install .DLL
    ?

    (I realise this is straying off Java, but if anyone can
    suggest a good search that will get me around the
    extremely brief and generic string 'so' - let me know!)

    (1) <https://jogl.dev.java.net/webstart/jogl.jnlp>
    It is listed as a library/extension (with no main)
    so there is no application will jump on-screen
    if you follow the link.

    Andrew T.
     
    Andrew Thompson, Sep 16, 2006
    #1
    1. Advertising

  2. Andrew Thompson wrote:
    ....
    > (I realise this is straying off Java, but if anyone can
    > suggest a good search that will get me around the
    > extremely brief and generic string 'so' - let me know!)


    Try:

    ".so" "shared object"

    Patricia
     
    Patricia Shanahan, Sep 16, 2006
    #2
    1. Advertising

  3. Patricia Shanahan wrote:
    > Andrew Thompson wrote:
    > ...
    > > (I realise this is straying off Java, but if anyone can
    > > suggest a good search that will get me around the
    > > extremely brief and generic string 'so' - let me know!)

    >
    > Try:
    >
    > ".so" "shared object"


    Thanks - even though my common search engine ignores
    the '.' of '.so' (which is very irritating), the addition of the
    expanded name was enough for me to confirm that a
    'shared object' is roughly equivalent to a '.dll'.

    Andrew T.
     
    Andrew Thompson, Sep 16, 2006
    #3
  4. Andrew Thompson

    PofN Guest

    Andrew Thompson wrote:
    > When it comes to the JMF PP, it is normally supplied in
    > an .EXE for Win., which I am guessing installs DLL's, and
    > for the Unix/Linux boxes, there is a .BIN file.
    >
    > Am I correct in my (wild ass) guess that the crude
    > equivalence might be expressed as..
    > *nix | .BIN - when run might install .SO
    > Win. | .EXE - when run might install .DLL
    > ?


    Unix is case sensitive. So it is .bin and .so, not .BIN or .SO

    ..bin has no real meaning on Unix. File extensions don't define if
    something can be executed or not, file attributes do. That makes some
    people (Windows developers) so nervous that they slap made-up
    extensions like .bin onto something which should be executable. If an
    executable on Unix has an extension, it typically identifies the
    interpreter language and format used to write it. E.g. .sh: shell
    script, .shar: self-extracting shell archive, .pl: perl, etc. It does
    not identify if the file is executable.

    ..so is by convention the extension for a shared binary object. It
    contains position-independent code (pic), so it is easily relocatable.
    This makes it suitable for dynamic linking and loading. When loading,
    code and read-only data is shared between several processes.
     
    PofN, Sep 16, 2006
    #4
  5. PofN wrote:
    > Andrew Thompson wrote:

    ...
    > > Am I correct in my (wild ass) guess that the crude
    > > equivalence might be expressed as..
    > > *nix | .BIN - when run might install .SO
    > > Win. | .EXE - when run might install .DLL
    > > ?

    >
    > Unix is case sensitive. So it is .bin and .so, not .BIN or .SO

    (snip)

    Thanks for the clarification. (I attempt case-sensitive
    searches at times)

    Oh.. and as an update to my original quest.

    I realised that the JMF '.bin' files I had could be renamed
    to .zip and extracted - I have now got hold of the
    shared objects that I wanted, and jar'd and signed
    them for use with WebStart.

    Of course - it is another matter as to whether any
    of this actually works on a *nix system.
    Further details are in the 'Can JMF be webstarted?' thread
    <http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/c43c1c15130e7bf6/c4167f6c7cda5c82?#c4167f6c7cda5c82>

    Andrew T.
     
    Andrew Thompson, Sep 16, 2006
    #5
  6. Andrew Thompson

    PofN Guest

    Andrew Thompson wrote:
    > I realised that the JMF '.bin' files I had could be renamed
    > to .zip and extracted


    Not surprising. Building self-extracting zip archives under Unix is so
    simple, people usually don't believe it.

    Create zip file:

    zip my.zip files ...

    Create extractor script:

    $ emacs extract
    #!/bin/sh
    exec unzip -o "$0"

    Concatenate the two files

    cat extract my.zip > self-extracting-archive

    Make it an executable

    chmod a+x self-extracting-archive

    Done. If you don't want to have the zip warning about junk characters
    at the start of the archive, throw in an extra call to dd.
     
    PofN, Sep 17, 2006
    #6
  7. Andrew Thompson

    Tarkin Guest


    > Thanks - even though my common search engine ignores
    > the '.' of '.so' (which is very irritating), the addition of the
    > expanded name was enough for me to confirm that a
    > 'shared object' is roughly equivalent to a '.dll'.
    >
    > Andrew T.


    With google, and others (AFAIK), you can do searches for literals
    with "". So, to look for .so, you type ".so". Note that this also
    makes the search case sensitive; ".so", ".SO",".So", and ".sO"
    are all different searches. This is especially useful for searching
    for specific error messages, to wit:

    A search for ' null pointer exception ' returns any and all pages
    containing these terms in any order:
    null
    pointer
    exception
    null pointer
    null exception
    pointer exception
    pointer exception null.

    Whereas a search for ' "null pointer exception" ' returns
    any and all pages containing that exact phrase, with
    the word order intact.

    HTH,
    Tarkin
     
    Tarkin, Sep 17, 2006
    #7
  8. Andrew Thompson

    Chris Uppal Guest

    Tarkin wrote:

    > With google, and others (AFAIK), you can do searches for literals
    > with "". So, to look for .so, you type ".so". Note that this also
    > makes the search case sensitive; ".so", ".SO",".So", and ".sO"
    > are all different searches.


    That's true for some of the others (such as ones based on the FAST engine), but
    not of Google.

    -- chris
     
    Chris Uppal, Sep 17, 2006
    #8
  9. In article <>,
    "PofN" <> wrote:

    > Andrew Thompson wrote:
    > > I realised that the JMF '.bin' files I had could be renamed
    > > to .zip and extracted

    >
    > Not surprising. Building self-extracting zip archives under Unix is so
    > simple, people usually don't believe it.
    >
    > Create zip file:
    >
    > zip my.zip files ...
    >
    > Create extractor script:
    >
    > $ emacs extract
    > #!/bin/sh
    > exec unzip -o "$0"
    >
    > Concatenate the two files
    >
    > cat extract my.zip > self-extracting-archive
    >
    > Make it an executable
    >
    > chmod a+x self-extracting-archive
    >
    > Done. If you don't want to have the zip warning about junk characters
    > at the start of the archive, throw in an extra call to dd.


    Not to be overlooked in this is the practice of using .bin for a file
    that contains a script at its beginning with embedded binary parts also
    present. This is what InstallAnywhere does for the installers it
    creates for all *nix platforms. When executed from the command line by
    way of their recommended command (e.g., "sh installer.bin"), the script
    begins running and, as part of its task, extracts from the binary
    portion what it needs.

    = Steve =
    --
    Steve W. Jackson
    Montgomery, Alabama
     
    Steve W. Jackson, Sep 18, 2006
    #9
  10. Andrew Thompson

    PofN Guest

    Steve W. Jackson wrote:
    > Not to be overlooked in this is the practice of using .bin for a file
    > that contains a script at its beginning with embedded binary parts also
    > present. This is what InstallAnywhere does for the installers it
    > creates for all *nix platforms.


    Yeah, Windows programmers getting nervous about the fact that
    extensions are not needed and have no special meaning on Unix. So they
    slap a meaningless .bin onto the file name to feel better.

    > When executed from the command line by
    > way of their recommended command (e.g., "sh installer.bin"), the script
    > begins running and, as part of its task, extracts from the binary
    > portion what it needs.


    InstallAnywhere is much worse. It first installs an "installation
    engine" (Universal/common/Gen1/engine/1.0). Then they bootstraps the
    installation via this engine. Net effect: An installation of a few
    files which would normaly take a few seconds on Unix now takes no less
    than 15 or 20 minutes. Of course InstallAnywhere never deinstalls this
    engine gunk.

    That happens when you transfer fucked-up Windows concepts to Unix. Add
    lazy application developers into the mix and you have another skrewed
    installation. If an application programmer can't write a simple Unix
    installation shell script, can't create a tar ball, can't create a shar
    or can't create a particular package manager's installation package or
    is to stupid to use Web Start he should stay away from Unix.

    Typically in the case of InstallAnywhere silent, command line
    installation is broken. It is beyond the mental capabilities of windows
    programmers to envision that command line installations are good. So
    deployment on multiple machines means PAIN with click until you die
    stupidity.
     
    PofN, Sep 20, 2006
    #10
  11. Steve W. Jackson wrote:
    > Not to be overlooked in this is the practice of using .bin for a file
    > that contains a script at its beginning with embedded binary parts also
    > present. This is what InstallAnywhere does for the installers it
    > creates for all *nix platforms. When executed from the command line by
    > way of their recommended command (e.g., "sh installer.bin"), the script
    > begins running and, as part of its task, extracts from the binary
    > portion what it needs.


    There are also other software well known to this forum that
    does that !

    :)

    Arne

    PS: For those that has not guessed it -
    http://java.sun.com/j2se/1.5.0/install-linux.html#self-extracting
     
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=, Sep 21, 2006
    #11
  12. In article <>,
    "PofN" <> wrote:

    > Steve W. Jackson wrote:
    > > Not to be overlooked in this is the practice of using .bin for a file
    > > that contains a script at its beginning with embedded binary parts also
    > > present. This is what InstallAnywhere does for the installers it
    > > creates for all *nix platforms.

    >
    > Yeah, Windows programmers getting nervous about the fact that
    > extensions are not needed and have no special meaning on Unix. So they
    > slap a meaningless .bin onto the file name to feel better.


    Not true. Despite the lack of "need" for extensions, it's been a very
    common practice in the *nix world to use them whether needed or not for
    quite a long time.

    > > When executed from the command line by
    > > way of their recommended command (e.g., "sh installer.bin"), the script
    > > begins running and, as part of its task, extracts from the binary
    > > portion what it needs.

    >
    > InstallAnywhere is much worse. It first installs an "installation
    > engine" (Universal/common/Gen1/engine/1.0). Then they bootstraps the
    > installation via this engine. Net effect: An installation of a few
    > files which would normaly take a few seconds on Unix now takes no less
    > than 15 or 20 minutes. Of course InstallAnywhere never deinstalls this
    > engine gunk.


    I take it you don't actually use InstallAnwyhere -- or at least not in a
    very long while. If you did, you might know that what you just said is
    patently false. InstallAnywhere is primarily Java driven. Its first
    step is to unbundle a private JRE to run its own "engine", as you call
    it, and it does in fact clean up after itself.

    > That happens when you transfer fucked-up Windows concepts to Unix. Add
    > lazy application developers into the mix and you have another skrewed
    > installation. If an application programmer can't write a simple Unix
    > installation shell script, can't create a tar ball, can't create a shar
    > or can't create a particular package manager's installation package or
    > is to stupid to use Web Start he should stay away from Unix.
    >
    > Typically in the case of InstallAnywhere silent, command line
    > installation is broken. It is beyond the mental capabilities of windows
    > programmers to envision that command line installations are good. So
    > deployment on multiple machines means PAIN with click until you die
    > stupidity.


    I'm not in the habit of defending Windows -- I dislike it intensely and
    would never touch it if not required to do so. But you've somehow got a
    serious dislike for InstallAnywhere, which has been an outstanding
    product for me now for five years. I fail to see anything about it that
    suffers from adoption of bad Windows habits.
    --
    Steve W. Jackson
    Montgomery, Alabama
     
    Steve W. Jackson, Sep 21, 2006
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kevin Mitchell

    Can "bin" be changed to "cgi-bin" for asp.net

    Kevin Mitchell, Oct 19, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    913
    Wim Hollebrandse
    Oct 19, 2003
  2. John Salerno
    Replies:
    30
    Views:
    2,003
    Stephan Kuhagen
    Aug 10, 2006
  3. sweety
    Replies:
    9
    Views:
    1,045
    Richard Heathfield
    Feb 7, 2006
  4. Yves Dorfsman

    #!/usr/bin/env python vs. #!/usr/bin/python

    Yves Dorfsman, May 2, 2008, in forum: Python
    Replies:
    27
    Views:
    2,046
    Tim Roberts
    May 10, 2008
  5. anne001
    Replies:
    1
    Views:
    529
Loading...

Share This Page