Can some one explain what it means in simple terms. Does it mean the environment (DOS, Windows, Linux, etc) where the application codes are run?
Distinguish this from Development Environments and Build Environments.
You will tend to find a hierarchy here.
Run time environment - Everything you need to execute a program, but no tools to change it.
Build environment- Given some code written by someone, everything you need to compile it or otherwise prepare an executable that you put into a Run time environment. Build environments are pretty useless unless you can see tests what you have built, so they often include Run too. In Build you can't actually modify the code.
Development environment - Everything you need to write code, build it and test it. Code Editors and other such tools. Typically also includes Build and Run.
Yes, including all the settings (like environment variables), common libraries(!), directory structure, network neighbors e.t.c
The runtime environment can also be a virtual machine, such as the JRE (Java Runtime Environment) or CLR (Common Language Runtime) for .NET framework.
What is the target of your program? Does the program run on top of the JRE, CLR? Or are you compiling into a binary file that is run by your operating system?
The main question is what is that target of your program. How will your program be executed?
As soon as a software program is executed, it is in a run-time state. In this state, the program can send instructions to the computer's processor and access the computer's memory (RAM) and other system resources.
RTE allows the program to be run in an environment where the programmer can track the instructions being processed by the program and debug any errors that may arise.
While developers use RTE software to build programs, RTE programs are available to everyday computer users as well,e.g software such as Adobe Flash Player
Source
To add to the other answers given, I would say that Runtime environment is an environment, which supports the execution of a program/process. A program, for being able to execute, requires runtime environment. Runtime environment provides following services to the program/process :-
Resident Memory
Resources such as File, Sockets, etc.
Environment variables
Proper initialization
Proper disposal.
In short, Runtime environment is for the program, what physical environment is to us. Program/process can't sustain without runtime environment.
I am working on compilers and the Runtime environment means ,it is the structure of the target computers registers and memory that serves to manage memory and maintain information needed to guide the execution process.
infact, almost all programming languages use one of three kinds of runtime environment,whose essential structure does not depend on the specific details of the target machine.
These three kind of runtime environmenta are
fully static environment( example FORTRAN77)
stack-based environment(C,C++)
Fully dynamic environment(LISP)
It refers to the collection of software and hardware resources that enable a software program to be executed on a computer system. The runtime system is a composite mechanism designed to provide program execution services, regardless of the programming language being used
Simple and Generic definition
Let's not make it so complicated, in context of software engineering a runtime environment is simply an environment that a piece of software needs to run.
For example you might have Googled PC Requirements for GTA-V and you found the following answer:
Minimum System Requirements:
OS: Windows 8.1 64 Bit, Windows 8 64 Bit, Windows 7 64 Bit Service Pack 1
Processor: Intel Core 2 Quad CPU Q6600 # 2.40GHz (4 CPUs) / AMD Phenom 9850 Quad-Core Processor (4 CPUs) # 2.5GHz
Memory: 4GB
Video Card: NVIDIA 9800 GT 1GB / AMD HD 4870 1GB (DX 10, 10.1, 11)
Sound Card: 100% DirectX 10 compatible
HDD Space: 65GB
What are these? These are the environment variables which you need to run GTA-V, another way to say the same thing is:
This is runtime environment for GTA-V.
Take example of Node.js, when you say Node.js is JavaScript runtime environment you simply mean that Node.js provides everything (from software perspective) to run JavaScriptic code on the hardware (Mobiles, Laptops, etc). That everything includes interfaces to the Operating Systems of that particular hardwares.
Note: Both of the below statements are correct:
Node.js is JavaScript runtime environment (RTE).
Node.js and OS on which Node.js is installed makes Runtime Environment for JavaScript.
Technical definition
Runtime environment, primarily implements portions of an execution model.
The execution model specifies the behavior of elements of the language. By applying the execution model, one can derive the behavior of a program that was written in terms of that programming language.
Ok I know that console.log("Hi") shows me hi on the console, but how this behaviour of that particular string (console.log) is achieved?
Some or all the underlying steps which were taken between the execution of code and logging of the output constitue runtime environment.
Related
I am currently taking a class on Assembly Language and Computer Architecture. We're programming in MASM for x86 processors. I have a Macbook Air, so of course I have to run Windows on a virtual machine to program in MASM for our assignments.
What I'm confused about: We're learning about, and programming for x86 architecture. When I looked up my Macbook Air's processor, it seemed to be in the x86 family. Considering that, why doesn't MASM work with Mac OS X?
Furthermore, if assembly language communicates directly w/ hardware, why does merely installing the Windows OS (or running it through a VM) on Apple Hardware suddenly allow me to program in MASM?
Thanks,
Ian
[EDIT for clarification: My understanding -- please tell me if i'm wrong -- is that Assembly Language is as "low as you can go." I.e. it's pre-operating system, and provides instructions directly to the hardware itself. Thus, I don't understand why an assembly language for x86 architecture doesn't work on ALL x86 machines, regardless of OS]
Programs are made up of more than just the raw machine code. The executable needs to have a special format that the OS can understand, so it can load and run the code. Also, the code expects a certain environment, such as libraries and system calls (along with the appropriate calling conventions).
To compile and run your assembly program you need to assemble it first, that is run it through MASM in this case. However, MASM itself is a windows executable. It is in the executable format for windows, and it uses libraries and operating system functions accordingly. As such, you can't run it directly on mac os. Afterwards, you typically also need to link your code, which has the same issues. The next problem is with the program itself. MASM (and the rest of the toolchain) is by default also targeting windows (or dos) and so the created program has the appropriate format.
You can theoretically create a program intended to run on mac os using windows and masm. This is called cross-compiling in general. If your toolchain does not support the required mac format, you will need to create everything by hand. You obviously also need to write your program such that it expects the mac environment. For example, you can't use dos interrupts or windows libraries.
Since the architecture is the same, you don't need to virtualize the cpu. You can get away with emulating just the environment. An example for this is the windows emulator, wine, or cygwin emulating unix on windows.
A very rough analogy: there are human languages that use the same alphabet, but you still need to translate. There are also languages that do not even use the same alphabet, or don't even have letters. You will need to do more work in these cases.
I try to understand this whole "compiling" topic in a way more detailed than all those "what is a compiler (doing)?" articles out there.
One big question to me is processor- and os-platform dependency when compiling directly to machine code (e.g. C). I try to formulate concrete questions that needs to be resolved in order to get my picture clearer:
I compile my C code via gcc on a Linux distribution... :
Can I run the resulting executable on any other Linux Distribution?
Is that executable bound the processor platform compiled on? Do I need to search for another e.g. power-pc gcc when I am running a x86 distro?
Can I somehow execute this on windows? I know executables differs but the binary code is the same, isn't it?
So in the end my questions aims on: Is compiling about targeting a specifiy OS paltform, processor platform or both?
Thanks!
Compiling targets both, OS, and Architecture.
The OS needs to be targeted because:
The format of what is an "executable" file is different among operating systems.
Programs call the operating system even for common tasks like writing to the console, reading from a file, or terminating cleanly (standards like POSIX mitigate OS dependencies by defining a common layer between the program and the OS).
The CPU architecture must be targeted because the CPU instructions are different, even among different generations of the "same architecture".
Can I run the resulting executable on any other Linux Distribution?
In general, Yes, but on specific cases it may depend on the type of program (f.i. GUI) and the services assumed available on the OS.
Is that executable bound the the processor platform compiled on? Do I need to search for another e.g. power-pc gcc when I am running a x86 distro?
I don't understand what you mean by "search", but, Yes, you can cross-compile from, say, x86 targeting PPC.
Can I somehow execute this on Windows? I know executables differ but the binary code is the same, isn't it?
These days Windows has Ubuntu integration, and that allows for some kind of exceptions, but the general answer is No, because of the above.
I deployed a matlab script to an executable file which runs on linux platform.
let's say file :
$./run_test.sh
As it is created on linux, it cannot be executed on the powerPC CPU.
Is there any way to translate the binary file to a PPC readable file?
Thanks
You're mixing OS & CPU issues: the problem isn't that it was created on linux (there are versions of linux that run on PPC); the problem is that it is for a different CPU (x86, most likely). And other than running an emulator/simulator for that processor on you PPC box (which, if it works, would likely be quite slow), or getting a hold of the source to re-compile it, I believe you are out of luck.
...unless of course this really is a script, and while executable is not binary, in which case your solution may be as simple as changing the line endings. This is likely the case if you can open it in a text editor & you can read it (that is, it isn't full of funky symbols).
Complementing Scott's answer. If you have the source code of the application, you can use Software Development Toolkit for Linux on Power to help you in the migration.
The IBM Software Development Kit for Linux on Power (SDK) is a free, Eclipse-based Integrated Development Environment (IDE). The SDK integrates C/C++ source development with the Advance Toolchain, Post-Link Optimization, and classic Linux performance analysis tools, including Oprofile, Perf and Valgrind.
Since I have started to learn Golang since yesterday :) I have a question about the compiled file.
Let's assume that I compile my project. It generates an .exec file in /bin folder.
Now my question is Since the file has been compiled on Mac with Intel based CPU, should it be compiled on other OS and other CPU architectures such as AMD, ARM, etc. if I want to publish it to public?
I guess this should not be problem if I'm using GO lang for my backend since I run it on a server. However, what happens if I publish my .exec file, let's say on AWS, with lots of instances that they are automatically increases/decreases based on load? Does it problem?
Edit:
This is nice solution for those how are looking Go cross compiling tool https://github.com/mitchellh/gox
The answer to the first question is yes. The current implementations of Go produce a native binary, so you will probably need a different one for Linux x86 (32-bit), Linux x64 (64-bit), and Linux ARM. You will probably need a different one for Mac OS X also. You should be able to run the 32-bit executable on a 64-bit system as long as any libraries you depend on are available in 32-bit form on that system, so you might be able to skip making a 64-bit executable.
In the future, there may be other implementations of Go that compile for a virtual machine (such as JVM or .NET), in which case you wouldn't need to compile multiple versions for different architectures. Your question is more about existing Go implementations than the language itself.
I don't know anything about AWS, but I suggest you ask that as a separate question.
While it's my understanding that there's no fundamental reason a program written for 32-bit hardware / OSs not to run on 64-bit hardware / OSs, in practice, I've found many programs intended for 32-bit versions of Windows that will not work on 64-bit versions of Windows. Examples include a number of popular security utilities (most products from Norton and Check Point's Zone Alarm) and several games (I've been trying to get Grand Theft Auto 4 to run for a few weeks now, but to no avail - of course, that might be related to any number of other problems related to GTA4, but that's neither here nor there).
I've heard that a program's incompatibility might result from something as simple as not wanting to run from the "Program Files (x86)" folder, but what are some of the other reasons? Why would a virus scanner or firewall written for a 32-bit system not run on a 64-bit system? Why would a game not run when everything is theoretically backwards-compatible?
There is a lot of misinformation on this thread.
When a 32-bit application is run on 64-bit windows:
Most of the compatibility problems come when the application tries to install a kernel-mode driver. A 32-bit driver can't be installed on the 64-bit OS. This is amost certainly the problem with a firewall. It's trying to hook into the TCP/IP driver stack.
THERE IS NO EMULATOR! The 32-bit object code is executed by the cpu completely natively at full speed.
There is no support for old 16-bit code. This broke a lot of installers.
Accessing the right folders is generally not a problem. When a 32-bit program opens a file in, say %windir%\system32\, the OS automagically redirects it to %windir%\syswow64. The same for certain parts of the registry. There are a few potential gotchas here, but they're generally along the lines of assuming that various WINAPI Get...Directory() functions return the same strings that they did in Windows 95.
Whether it was compiled 10 years ago or just yesterday, then C/C++ pointers are still 32-bits (4 bytes) and all of the code that just assumed that -- including SendMessage()! -- still works. The 8-byte pointer issue doesn't come into the picture until you start converting to 64-bit compilers.
The best explanation I've found is offered here which basically says 32-bit programs are run on an layer of emulation which doesn't allow the system access you'd get from native programs run in a 64-bit environment:
http://blogs.msdn.com/oldnewthing/archive/2008/12/22/9244582.aspx
I would assume this means that problems with programs like GTA4 come from the layer of emulation not producing the expected results found on a 32-bit native system. This is why you keep seeing Microsoft release compatibility updates all the time.
Here's what the MSDN has to say about the matter:
http://msdn.microsoft.com/en-us/library/bb427430(VS.85).aspx
Drivers are a different story that programs:
http://support.microsoft.com/kb/896456
Zone Alarm uses a special 32-bit driver created by Check Point to do the monitoring. This is probably what's creating the issue with that application. As for Grand Theft Auto 4? I have no idea.
There can be any number of reasons.
Any application which is programmed ad a low level might be expecting 32 bit register. The Zone Alarm driver posted by novatrust is a good example. GTA4 might be using assembly to improve performance at several points which might result on anything or even simply assuming 32 bits on C++. For example take the following code:
struct GPoint
{
int x;
int y;
}
// Array of twenty GPoints
GPoint[] myArr = malloc(20 * sizeof(GPoint);
GPoint* myPointer = myArr;
int index = GetIndexAffectedPoint();
// Invert X and Y for the point
myPointer += 8*index;
swap(myPointer);
I know the example is pretty naive but anyway, in that code you are assuming you're struct is 8 bytes long (4 bytes of the x integer and 4 bytes for the y integer) but in a 64 bit system is actually twice that long so you'll end up swapping the wrong point... things like that happen a lot on low level languages, specially when trying to improve performance...
Security applications are a bad example. They all perform unsupported things against undocumented things. Changes between one 32-bit version of Windows to the next are enough to break them, nevermind moving to 64-bit.
That said, there are some compatibility shims that fixup your code on 32-bit that won't when the app is 64-bit. This is because Microsoft assumes you've tested it on 64-bit.
One resulting gotcha is with .NET applications. When running on a 32-bit system, the exe is jitted to 32-bits - where there are compatibility shims to fix your bugs. If your customer happens to be running on a 64-bit system, the executable will be jitted to 64-bits, where those compatibility shims that were protected you from yourself are no longer present.
Chris Jackson had a nice blog entry about this: Shimming Applications on Windows Vista 64-Bit
The problem is probably drivers. With games, it's probably some kind of slimy DRM scheme. Try getting the no-CD crack for the game so you can run it without DRM.
32-bit to 64-bit Migration Considerations
EDIT: Alternative link
If you are using the file system or the registry, make sure that you access the right folders. As a x86 program you will probably want to access "Program Files (x86)", "SysWOW64", "WOW6232Node" and such folders instead of the x64 ones.
Products with x86 applications like Norton and Check Point's Zone Alarm fail to run their x86 driver, as the driver needs to x64 to be able to ran by the operating system.