«

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 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 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 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 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 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.

> 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 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

In article < .com>,
"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 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 ****ed-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.