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

[Andrew Thompson]

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.

 

[Patricia Shanahan]

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

 

[Andrew Thompson]

Andrew Thompson wrote:
...

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.

 

[PofN]

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.

 

[Andrew Thompson]

Andrew Thompson wrote: ...

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...15130e7bf6/c4167f6c7cda5c82?#c4167f6c7cda5c82>

Andrew T.

 

[PofN]

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.

 

[Tarkin]

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

 

[Chris Uppal]

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

 

[Steve W. Jackson]

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 =

 

[PofN]

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.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

 

[Steve W. Jackson]

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.

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.