 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2006Relationship .BIN/.SO & .EXE/.DLL?
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 a.s) 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. ... > (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 > ... > > (I realise this is straying off Java, but if anyone can [quoted text clipped - 4 lines] > > ".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. > 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 > 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 > When it comes to the JMF PP, it is normally supplied in > an .EXE for Win., which I am guessing installs DLL's, and [quoted text clipped - 5 lines] > 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. .. > > Am I correct in my (wild a.s) guess that the crude > > equivalence might be expressed as.. [quoted text clipped - 3 lines] > > 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/c43c1 c15130e7bf6/c4167f6c7cda5c82?#c4167f6c7cda5c82> Andrew T. > 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. > > I realised that the JMF '.bin' files I had could be renamed > > to .zip and extracted [quoted text clipped - 22 lines] > 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 =  SignatureSteve W. Jackson Montgomery, Alabama > 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 f.cked-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. > > 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 [quoted text clipped - 4 lines] > 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 [quoted text clipped - 7 lines] > 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 f.cked-up Windows concepts to Unix. Add > lazy application developers into the mix and you have another skrewed [quoted text clipped - 8 lines] > 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. SignatureSteve W. Jackson Montgomery, Alabama > 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 [quoted text clipped - 3 lines] > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.