Tigersen wrote: ↑
Thu May 03, 2018 1:36 pm
How can you make an installable program for Raspi/Linux like for example chromium/kodi? I want to code, not use a program to make the new program. And what language?
I think there are some misconceptions here.
"I want to code, not use a program to make the new program." Taking this literally, the only way you could achieve this aim is to write in machine code.
Machine code is the actual noughts and ones stored in memory that tell the hardware what to do. I used to write in machine code for the Z80, which is an 8-bit microprocessor with a very simple instruction set, and is the only way to code if you have no access to an assembler. The process of writing machine code is an intellectual endeavour of working out what you want the processor to do, breaking it down into steps selected from the individual operations that particular processor is capable of doing (involving a great deal of pouring over manuals and data sheets), converting those steps into the binary code that actually drives the processor to perform the processes, somehow get the code into the memory, run it, and then try to figure out what the problem is when it doesn't work first time (or second time, or third...).
In short: it's very hard, but manageable on something as simple as a Z80 - but comparing a Z80 to a 4-core 64-bit Arm processor is like comparing a push bike to the top-of-the-line Ferrari. (A push bike has four instructions in its instruction set, and the rider provides the input: turn pedals; apply steering; apply brakes; change gear. For a Ferrari, well...)
The next level up is assembly code. This is an aid to the human programmer not to have to remember or look up the details of the binary representations of the instructions. It replaces the binary instructions with text symbols that are easier to remember, so you might write "NOP" (for "no operation") or "ADD R5" (for "add the content of Register 5 into the accumulator"). The programmer produces a text file containing the assembly code, and then uses a program called an "assembler" to convert the code into the binary for the processor. Assembly code is easier to write, read, understand, follow, and debug. The point is, it uses what computers are good at (tedious grind) so that the programmer can concentrate on the actual programming (working out what the processor is to do rather than the details of how you make it do it).
At some point, it was necessary to write machine code. The first assembler had to be written in machine code, because there was nothing else. However, now computers already exist, nobody ever has to write machine code. If a new processor comes along for which there is no existing assembler, an assembler is created for that processor (running on an existing processor) as the first step.
Even so, assembly code is rarely used now. It is still very tedious and unproductive. It will still take months to code and test a program that could be written in a few lines of a high-level language in a matter of minutes.
High level coding languages such as C, Python, Basic, etc etc, allow the programmer to express his/her wishes in terms that are not unlike how you would describe the problem as written English (but in a highly formalised way). Don't think of them as English, think of them as languages in their own right but specialised for expressing the very specific concepts that are needed for getting a computer to do something useful. Any job a computer can do can be done in any programming language (including assembly and machine code), but some concepts are easier to describe in some languages than in others - that's why there are so many. In the early days of computing, Fortran was targeted at scientific calculation while COBOL was best for the sort of jobs required for business computing.
All these are aids, taking the hard work (that computers are good at) out of the task of programming, so that the programmer can get on with what he/she needs to do rather than do the tedious stuff and lose sight of the goal. All of them (even an assembler) are programs helping the programmer to make a new program. They encapsulate a great deal of previous work by the programming community, and make it available for the benefit of the programming community.
It is a useful exercise for any programmer to try a bit and machine code programming, just to appreciate the benefits of using high-level languages, but to turn your back on them entirely would be like refusing to look in a book if you needed to know something that is already in the accumulated knowledge of human history.
Another aspect I have not touched on so far is the operating system. Loads of the basic stuff that used to have to be done within a program (eg the details of retrieving some data from a file held on the hard drive) is now looked after by a huge program called the Operating System, so instead of worrying about that the programmer just has to know how to interact with the OS - and all that is also taken care of by the high-level languages (specifically tailored for the particular OS).
However, to get back to the point, "I want to code, not use a program to make the new program." You should see from the above that using a program to make the new program is practically unavoidable and it would be foolish not to (except as an academic exercise, just once). I think what you really meant was "I want to compile executable code not run my program through an interpreter".
An interpreter (as opposed to a compiler) provides a simulated program execution environment. It is, effectively, a program which "pretends to be" a processor with an instruction set that corresponds with the actual programming language. The advantage of an interpreter is that you don't need to convert ("compile") your code into the binary instructions for the particular processor - if an interpreter is written for any processor, the same code will run on all processors regardless of their instruction set. The disadvantage is that to run the code at all, the interpreter has to exist and it has to be installed on the system that is to run the code. A huge advantage of interpreters is they make it very easy to see what the code is doing, step by step if necessary, so you can work out why it isn't doing what you intended. Forth is one of the simplest interpreted languages, Java and some versions of a BASIC are also interpreted. Even BASH (one of the shell scripting languages available in Linux) is an interpreter.
A compiler is what takes program code in a high-level language and produces the binary processor instructions for any particular processor in combination with any particular operating system. On a standard PC (x86 processor with MS-DOS or Windows) the executable binary file is a .exe (or .com, or .bin). In Linux, an executable binary file can be called anything (it has to be given "executable" status in its file properties). So what you want is a compiled language - C, Python... take your pick. Some languages can even be run interpreted (for debugging) and
produce compiled output.
Debugging compiled machine code would be the mother of all programming tasks if it were not for tools that can intervene between the machine code and the processor so that the execution is effectively "interpreted". Even so, although the machine code can be stepped through, it would be hard to relate that to the original high-level language source were it not for a compiler option to include debug information in the executable. This makes a much larger executable, but includes info that allows the debugger to show you where you are in the original source code. (And of course, you don't publish an executable with the debug info in it - it would give away too many secrets! This has happened!!!)
And finally, there's "packaging". What you get from a repository download (be that a .tar, .deb, whatever) is a zipped collection of files that are needed to install and run a particular program suite. That will include the main executable, but also other executables it depends on, configuration files, data files, whatever. If your compiled program runs alone (under the operating system without further additions), you don't need to package it.
Post Script: It is entirely possible to produce code that can be compiled to a binary image, written to a memory card, installed into the RPi, and is executed from power up to control the whole operation of the RPi. This is called "bare metal", and there is a section of this forum dedicated to its discussion. An operating system, such as Linux, is effectively Bare Metal Programming, but if you want your RPi hardware to do something relatively simple immediately it is turned on all the time it is turned on, this is a way to do it.