Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I know that exe file contains pure CPU instruction plus extra piece of data. So if I begin running a simple hello world console app or a 32 bit GUI app (exe file) then the OS will load the instruction given in the exe file into memory to get processed by CPU. So if I run that app, it should only follow instruction as it is, that is to display hello world only (in a complete blank screen with only the word 'hello world'). But it is not happening so. It is somewhat controlled by OS to display in a windowed environment of command prompt. So what is actually happening there.
edit: To be precise my question is that i want to know what are all the instruction that an exe(a simple 16bit dos app in windows OS) file contains(considering the confusion above I have)?
If you compile a program on a particular OS, that it is that OS that you should run it on. For example, if you compile a command line program for Windows, it will work on Windows, but it will not work on Ubuntu. You said yourself that the content of the executable file differs from OS to OS.
What you can do is to use an emulator for a particular system on another system. For example, if you are on Linux, you can use Wine to run Windows programs. In this way you emulate the Windows environment for your program even though it is on Linux.
Of course, the CPU should follow the instructions as they are. If you, e.g., want to print a hello world line, than your program contains code for that. But not just for that. It contains the code for other stuff that are OS dependent, and this is where the problem is. For example, your Windows compiled program might use some Windows API to perform the printing, and this API is not to be found on Linux. It is than the called API, and not your program that directly performs the output.
As Jongware mentioned it in the comment below, what you could do is to cross-compile your code. In that case you can compile your code on Windows so that it can run on Linux, but only if you compile it with the libraries needed for the specific Linux. In that case, however, you will not be able to run you code on Windows.
By default, software are compiled for the same type of machine that you are using. However, you can also install a cross-compiler, to compile for some other type of machine.
When you develop a desktop or server application, almost always the development platform (the machine that runs your compiler) and the target platform (the machine that runs your application) are the same. By "platform" I mean the combination of CPU architecture, and Operating System. The process of building executable binaries on one machine, and run them on another machine when the CPU architecture or the Operating System are different is called "cross compilation". A special compiler is needed for doing cross compilation that is called "cross compiler", and sometimes just "toolchain".
have a look here and here.
So if I run that app, it should only follow instruction as it is, that is to display hello world only (in a complete blank screen with only the word 'hello world').
Why "complete blank screen"? It completely depends on how your application is designed:
In a console application, it will output the string to stdout, which is then displayed inside the console you started the program out of. If you started it directly via a shortcut or by double-clicking the .exe file, it will open a new console window.
In a windowed application, it will output the string wherever you defined it to be output.
Alas, your question is by far too vague to become more concrete here.
But it is not happening so. It is somewhat controlled by OS to display in a windowed environment of command prompt.
What does that mean?
If it means what I think, i. e. you indeed get a black window with the string output, well, it is exactly how it is supposed to work, if it is a console application.
Related
This question was migrated from Super User because it can be answered on Stack Overflow.
Migrated 12 days ago.
sorry if this question isn't in the right place, but I wouldn't qualify myself as a developer.
Overview: our organization runs a piece of critical Python code on Google's Collab from Google Drive. This code processes sensitive data and for privacy reasons, we'd like to move it out of Google. There's also a performance reason as the RAM requirements are sometimes higher than allowed by the free plan, halting code execution.
The setup: the code takes one very large PDF file as input (in the same Google Drive directory), processes it then spits out tens of usable XLSX files containing the relevant info, each in a different folder since the code is expected to be run once every 4-5 weeks. The very few parameters allowed are set in a simple text file.
The bug: no one in the organization currently has the skills to edit code and maintain a compatible Python environment.
The ideal end product would be a self-contained executable with no external dependency, able to run in any user directory. I know this is a rather inefficient use of disk space, but the only way to ensure proper execution every time. Primary target platforms would be Mac OS X 10.14 to current, or Debian-based Linux distribution, more precisely Linux Mint. Windows compatibility isn't a priority.
What would be the proper way to make this code independant?
In .NET6 I want to retrieve the native handle (NOT the "Managed Thread ID") of the OS thread, on which the handle-retrieving function just runs, as a (possibly casted to) UInt32.
I found a solution for Windows (using the kernel's "GetCurrentWin32ThreadId"), but I want to have solutions also for Linux, MacOS and Android, assuming that the respective implicit OS' object models contain also "Thread Handles".
To avoid senseless reading time consuming tries to lead me on other paths: my question is very precise, please don't ask "why"s! And please avoid "you could try"s, because I don't have access to Linux-Computers, Macs, Smartphones, and don't want to bother others by intermediate tests and/or even "tries". I need concrete definitoric "code snippet" answers.
I need it 1. for debugging purposes, 2. for .NET-ManagedThreadPool monitoring (if it always works correctly), 3. cross-checking with the Visual Studio output (about finished threads) and 4. some other (also platform specific to be handled, native) functions/stuff (e.g. native thread coordination, cross-process).
My goal:
I want to deliver my program(s) [atm especially the "OpenSimulator"-software, including the server (Windows, Linux) as well as the user's viewer (Windows, Linux, MacOS, iOS)] with a target-platform-independent .NET6-".exe", and an OS-respective target-platform-specific .NET6-.dll as the respective implementation for certain interfaces, to bridge the yet current compatibility-gaps, something/somehow like MAUI tries to do, but generalized more complete on the logical (.NET6) layer.
Is it possible to write a program (make executable) that runs on windows and linux without any interpreters?
Will it be able to take input and print output to console?
A program that runs directly on hardware, pure machine code as this should be possible in theory
edit:
Ok, file formats are different, system calls are different
But how hard or is it possible for kernel developers to introduce another executable format called raw for fun and science? Maybe raw program wont be able to report back but it should be able to inflict heavy load on cpu and raise its temperature as evidence of running for example
Is it possible to write a program (make executable) that runs on windows and linux without any interpreters?
in practice, no !
Levine's book Linkers and loaders explain why it is not possible in practice.
On recent Linux, an executable has the elf(5) format.
On Windows, it has some PE format.
The very first bytes of executables are different. And these two OSes have different system calls. The Linux ones are listed in syscalls(2).
And even on Linux, in practice, an executable is usually dynamically linked and depends on shared objects (and they are different from one distribution to the next one, so it is likely that an executable built for Debian/Testing won't run on Redhat). You could use the objdump(1), readelf(1), ldd(1) commands to inspect it, and strace(1) with gdb(1) to observe its runtime behavior.
Portability of software is often achieved by publishing it (in source form) with some open source license. The burden of recompilation is then on the shoulders of users.
In practice, real software (in particular those with a graphical user interface) depends on lots of OS specific and computer specific resources (e.g. fonts, screen size, colors) and user preferences.
A possible approach could be to have a small OS specific software base which generate machine code at runtime, like e.g. SBCL or LuaJit does. You could also consider using asmjit. Another approach is to generate opaque or obfuscated C or C++ code at runtime, compile it (with the system compiler), and load it -at runtime- as a plugin. On Linux, use dlopen(3) with dlsym(3).
Pitrat's book: Artificial Beings, the conscience of a conscious machine describes a software system (some artificial mathematician) which generates all of its C source code (half a million lines). Contact me by email to basile#starynkevitch.net for more.
The Wine emulator allows you to run some (but not all) simple Windows executables on Linux. The WSL layer is rumored to enable you to run some Linux executable on Windows.
PS. Even open source projects like RefPerSys or GCC or Qt may be (and often are) difficult to build.
No, mainly because executable formats are different, but...
With some care, you can use mostly the same code to create different executables, one for Linux and another one for windows. Depending on what you consider an interpreter Java also runs on both Windows and Linux (in a Java Virtual Machine though).
Also, it is possible to create scripts that can be interpreted both by PowerShell and by the Bash shell, such that running one of these scripts could launch a proper application compiled for the OS of the user.
You might require the windows user to run on WSL, which is maybe an ugly workaround but allows you to have the same executable for both Windows and Linux users.
I'm trying to create a Linux software in C++ which need to run code in a protected environment on x86 and x86-64 processor.
My problem is to find a way to run code in protected environment, first, only on x86-64 (it's a technical part of processors way of working), I have see Local Descriptors Table, but I found it no more works on x86-64. I also heard about the Intel VT technology, but documents seems very complicated.
Have you any idea of ways to run code in a protected environment on linux and x86-64 inside a process?
My goal is to create something like an OS inside a linux process.
Like Windows or Linux does, I want the program runned inside my protected environment no to access part of my software, and make systemcall if needed. I believe I have found a way to do so, I esxplain it below.
I have found a way to do what I want:
Each time my program will switch from main part to the program inside, it will use mprotect (a function of Glibc on Linux) to change the right to access to lot of part of the memory of the process.
Each time the program inside will make a systemcall to my program, it will change back the right to access to the memory.
You may thinks it stays security issues, because the program inside can run any kind of code and access to system call to linux and so can access to not allowed things. But I believe I can use a tricky which would prohibit the code inside to start any kind of opcodes.
I want to run a program when my embedded Linux's desktop has started up, in the same way as Windows runs programs in the "Startup" folder. How can I do this?
Specifically, my target hardware is Beaglebone Black, the Debian variant (rev C board). The Window Manager is the default one.
In Linux these are called init scripts and usually sit in /etc/init.d. How they should be defined varies between different distros but today many use the Linux Standard Base (LSB) Init Script format.
Good readings on this:
https://wiki.debian.org/LSBInitScripts
https://www.debian-administration.org/article/28/Making_scripts_run_at_boot_time_with_Debian
There are multiple ways to start a program, it turns out. LXDE - the window manager - supports auto-start of .desktop files places in either ~/.config/autostart or /etc/xdg/autostart - hooray!
http://wiki.lxde.org/en/Autostart
Except... though I can run a simple program as proof-of-concept in this way, when I try to run mine, it fails. I can't figure out why. The file
.xsession-errors.old
contains X server errors ("resource temporarily unavailable").
I am now using another mechanism - running the code from a shell script (this is necessary because I need to specify a working directory for the program). This uses the "autostart" file in /etc/xdg/lxsession/, and at least it works. Well kind of. I either have to "sleep 5" before running, or prefixing the run with an # symbol which forces a retry if it fails. It looks a little like something my code is dependent on is not in place at the precise time the autostart mechanism finds it. I can find no way of ensuring startup order. This is plainly a crock of stinky stuff.