I often see the terms "binary" and "executable" seemingly used interchangeably for the same thing.
Ain´t it two terms to describe the exact same thing; The executable output program after a compilation process, which I can run on the terminal?
What do strengthen my assumption, that these two things shall be the same is also, that it is a common practice to provide a bin folder ("bin" as abbreviation for "binaries") inside the installation folders of an application, to store the executable files in, which users are be able to run.
I have read the question and answers of What's the difference between binary and executable files mentioned in ndisasm's manual? but the question and their answer are more focused on the respective environments of Clang and ndisasm.
I´ve also read the question and the answers of https://softwareengineering.stackexchange.com/questions/121224/what-are-binaries at the Software Engineering forum, but also here no distinction between an executable and a binary; only what the term of "binary" in general can refer to:
But, in Computing, Binary refers to :
Binary file, composed of something other than human-readable text
Executable, a type of binary file that contains machine code for the computer to execute
Binary code, the digital representation of text and data
[Source: https://softwareengineering.stackexchange.com/a/121235/349225]
where, in the context of the output program of a compilation process, a binary was referred to as the same as an executable, as well as:
The word binaries is used as a set of files which are produced after compiling essentially the object code that runs on machines. (and virtual machines/runtimes in case of Java/.NET)
[Source: https://softwareengineering.stackexchange.com/a/121234/349225
]
where it was referred to the same.
What is the difference between "binaries" and "executables" in the context of an executable program?
Where is the distinction?
An executable file is one which can be executed; you would run it on the commandline by writing the name of the file itself as the command. On Unix systems, the file's "executable" flag must also be set. On Windows, the file's extension must be one of a fixed set of executable file extensions, including .exe.
A binary file is simply one in a binary (i.e. non-text) format. The binary format means that the file's contents should not be transformed for platform-specific reasons (e.g. replacing newlines from \n to \r\n).
Binary files are not necessarily executable, for example a library compiled to .dll or .so form is a binary but not an executable. A Java program compiled to .class or .jar form is not an executable file, but might be run using the command java -jar program.jar rather than the command ./program.jar.
Executable files are not necessarily binary, for example a Python script in text form can be made executable on Unix systems by writing a shebang line #!/usr/bin/python3 and setting the file's executable flag.
It helps to understand the context of the term "binary" here. It originates from compilers, which take the (text-based) source code of a program and turn that source code into an excutable form which is binary, not text-based. Thus in the context of compilers, "text" and "source code" are equivalent, as are "binary" and "executable". Interpreters on the other hand do not make the distinction between source code and executable code.
Things definitely got more complex over time with intermediate representations, such as used by the Java JVM, .Net's CLI or Python bytecode.
It depends on the definition. All files contain binary code and a "working" definition is the following:
Binary or text files
Files's binary code encodes text: text file
Files's binary code does not encode text: binary file
Executable or non-executable files
File can be executed: executable file
File can not be executed: non-executable file
Therefore the binary and executable are orthogonal properties i.e. any file can either have them or not in an independedent way. Some examples:
Binary executable: The .exe files in Windows, .app in MacOS (not a single file but a bundle) etc.
Text executable: Python scripts, bash scripts (require the corresponding interprenters) etc
Binary non-executable: PDF files, audio files etc
Text non-executable: C++ source code, a markdown file etc
Related
Can anyone explain me what is the use of init.tcl?
When actually it is loaded by the TCL interpreter?
The description for this file is shown as
startup file for TCL .
But According to my knowledge .tclshrc is the start up file.
Can anyone explain this?
Actually, init.tcl is the first file that is loaded by a Tcl_Interp*.
Its job is to setup the different package loading mechanisms.
Some programs, most notably tclsh, will source the .tclshrc. This is usually done using Tcl_SourceRCFile.
So init.tcl is sourced for every Tcl interpreter, while the .tclshrc is only sourced by some programs that explicitly do that.
* does not apply to safe interpreters
I have a ".pcapng" binary file, created by Wireshark.
How to detect the beginning of every new package in it?
Is there any specific bytes sequence?
Alternatively, how to detect the end of a package?
(I've seen people whose native language isn't English speak of "packages" rather than "packets" - both words come from the same word "pack", and the same word may be used for both concepts in other languages - so I'm assuming you're referring to network packets; "packages" is generally not used in that sense in English.)
The pcap-NG file format is described in the PCAP Next Generation Dump File Format document. A pcap-NG file is a sequence of blocks; each block has a length field at the beginning (and at the end, to simplify scanning backwards through a file). Not all blocks contain packets; the blocks that do are the Packet Block, Extended Packet Block, and Simple Packet Block.
Note that libpcap 1.1 and later can read pcap-NG files, so any program that uses libpcap to read capture files can, if dynamically liked with libpcap and running on a system where the libpcap shared library is 1.1 or later, or statically linked with libpcap 1.1 or later, can read some pcap-NG files using the same APIs that are used to read pcap files, without any change to the program. (pcap-NG files containing multiple interfaces where not all of them have the same link-layer header type or snapshot length cannot be read, as the current libpcap APIs don't support that.) There is no version of WinPcap based on libpcap 1.1 or later, so WinPcap cannot currently be used to read pcap-NG files.
Another library that can read pcap-NG files is the NTAR library. It, however, can only read pcap-NG files, not pcap files.
In a Microsoft Access 2007 project the Access form objects are exported to files with a dedicated software by using the built-in function "SaveAsText". This is necessary because Access doesn't store any of it's code modules in isolated files at its own.
The file starts with the bytes "FF FE" (which is UTF-16 according to http://de.wikipedia.org/wiki/Byte_Order_Mark). I presume because of many NUL characters in this file, Hg treats this file as a binary file. Hence the diff pane in the TortoiseHG workbench always tells
File or diffs not displayed: File is binary.
which is quite understandable under this assumption. But nevertheless this file is just usual source code. I can view it for example in Windows' notepad without any problems.
Is there any way to tell Mercurial, that this particular file should be treated as text, not binary?
Edit:
Additionally to the marked preferred answer below I decided not to change the saving behaviour, but to use the "Visual Diff" command (select file, then press Ctrl+d) instead.
I'm guessing that you frequently or occasionally export the form objects in order to track source code changes.
The only way to convince Mercurial that a file is not binary is to avoid NUL bytes.
You may want to convert the source code files to ASCII (or maybe ANSI) encoding as an additional step in your export in order to avoid the NUL bytes. If the source code files contain Unicode characters, you might try UTF-8, as this will only do multi-byte characters when necessary and single-byte characters otherwise, thus avoiding NUL bytes again. I tried it out briefly and Mercurial handles UTF-8: it doesn't show "File is binary", but the actual diff. I committed on the commandline, but viewed the diff in TortoiseHg. I have a link about commandline encoding challenges below.
The hgrc encode/decode sections might be particularly useful in helping to filter the UTF-16 files into something that works better.
A couple other pages on Mercurial and encoding:
Character Encoding On Windows
Encoding Strategy
TortoiseHg 2.1 + Mercurial 1.9
From https://www.mercurial-scm.org/wiki/BinaryFiles:
The question naturally arises, what is a binary file anyway? It turns out there's really no good answer to this question, so Mercurial uses the same heuristic that programs like diff(1) use. The test is simply if there are any NUL bytes in a file.
For diff, export, and annotate, this will get things right almost all of the time and it will not attempt to process files it thinks are binary. If necessary, you can force these commands to treat files as text with -a.
This didn't exist at the time the question was asked, but now there's the msaccess-vcs-integration project, which exports/imports MS Access objects so that they can be version controlled.
Quote from the project's readme:
Encoding
For Access objects which are normally exported in
UCS-2-little-endian encoding , the included module automatically
converts to the source code to and from UTF-8 encoding during
export/import; this is to ensure that you don't have trouble
branching, merging, and comparing in tools such as Mercurial which
treat any file containing 0x00 bytes as a non-diffable binary
file.
If you export your forms and modules with this instead of directly using Access's SaveAsText function, Mercurial will not treat the files as binary.
I'm developing a tool that will perform several types of analysis, and each analysis can have different levels of thoroughness. This app will have a fair amount of options to be given before it starts. I started implementing this using a configuration file, since the number of types of analysis specified were little. As the number of options implemented grew, I created more configuration files. Then, I started mixing some command line parameters since some of the options could only be flags. Now, I've mixed a bunch of command line parameters with configuration files and feel I need refactoring.
My question is, When and why would you use command line parameters instead of configuration files and vice versa?
Is it perhaps related to the language you use, personal preference, etc.?
EDIT: I'm developing a java app that will work in Windows and Mac. I don't have a GUI for now.
Command line parameters are useful for quickly overriding some parameter setting from the configuration file. As well, command line parameters are useful if there are not so many parameters. For your case, I'd suggest that you export parameter presets to command line.
Command line arguments:
Pros:
concise - no extra config files to maintain by itself
great interaction with bash scripts - e.g. variable substitution, variable reference, bash math, etc.
Cons:
it could get very long as the options become more complex
formatting is inflexible - besides some command line utilities that help you parse the high level switches and such, anything more complex (e.g. nested structured information) requires custom syntax such as using Regex, and the structure could be quite rigid - while JSON or YAML would be hard to specify at the command line level
Configuration files:
Pros:
it can be very large, as large as you need it to be
formatting is more flexible - you can use JSON, YAML, INI, or any other structural format to represent the information in a more human consumable way
Cons:
inflexible to interact with bash variable substitutions and references (as well as bash math) - you have to probably define your own substitution rules if you want the config file to be "generic" and reusable, while this is the biggest advantage of using command line arguments - variable math would be difficult in config files (if not impossible) - you have to define your own "operator" in the config files, or you have to rely on another bash script to carry out the variable math, and perform your custom variable substitution so the "generic" config file could become "concretely usable".
for all that it takes to have a generic config file (with custom defined variable substitution rules) ready, a bash script is still needed to carry out the actual substitution, and you still have to code your command line to accept all the variable substitutions, so either you have config files with no variable substitution, which means you "hard code" and repeat the config file for different scenarios, or the substitution logic with custom variable substitution rules make your in-app config file logic much more complex.
In my use case, I value being able to do variable substitution / reference (as well as bash math) in the bash scripts more important, since I'm using the same binary to start many server nodes with different responsibilities in a server backend cluster, and I kind of use the bash scripts as sort of a container or actually a config file to start the many different nodes with differing command line arguments.
my vote = both ala mysqld.exe
What environment/platform? In Windows you'd rather use a config file, or even a configuration panel/window in the gui.
I place configuration that don't really change in a configuration file.
Configuration that change often I place on the command-line.
What is the difference between plain binary format (.bin) and Windows Executable (.exe)?
I'm not sure what a "bin" file is in this case. Could be a firmware, could be an object file, could be anything really (it depends on context).
When talking about executables (exe files in the case of windows) these are usually self contained packages with everything required to run them packed in. These file formats usually contain all the executable data, string and other resources, linking data and exports, offsets, and other data stuffed in them. They have everything required for the OS to setup and enviroment to run them, like the dependent libraries that need to be loaded, the architecture it needs to run, etc.
There are lots of different ones in common use:
PE your standard windows executable and dll format (http://en.wikipedia.org/wiki/Portable_Executable)
ELF used by Linux and other UNIX clones (http://en.wikipedia.org/wiki/Executable_and_Linkable_Format)
Mach-O used by your Mac executables (http://en.wikipedia.org/wiki/Mach-O)
a.out sort of legacy executable package (http://en.wikipedia.org/wiki/A.out)
Lots of others (COFF, COM, etc).
If the operating system supports dynamically linkable libraries (dlls on windows, .so files on linux, dylibs on mac) then they usually share this same packaging format.
There's no such thing as plain binary format. There's no known standard for what is in ".bin" files. Expect any data.
EXE is a file with a well-defined structure for storing code. It's called "Portable Executable" format, and has a PE header starting with MZ.
http://en.wikipedia.org/wiki/Portable_Executable
BIN:
The BIN file type is primarily associated with 'Binary File'. Binary files are used for a wide variety of content and can be associated with a great many different programs. In general, a .BIN file will look like garbage when viewed in a file editor
for more info Click here
EXE:
The EXE file type is primarily associated with 'Executable File' by Microsoft Corporation. An executable file is basically another name for a program. Virtually all programs that run under Windows or DOS are in the .EXE format
for more info click here