As the title said, with any possible tricks or bugs,can we create a binary file can run both on Linux and Windows without any change?
(The file must be directly created by a compiler)
I know it's nearly impossible,but with some tricky methods,is that possible?
Related
I've written a command-line application that allows me to copy certain files to and from the Desktop. And up until now it's been fine since I was on Ubuntu, but now I'm adding a Windows 7 machine that doesn't play well with my current implementation.
My current solution is to duplicate my scripts and hard code paths.
CANVAS_DIR = "#{HOME}/GitHub/canvas"
gets replaced with:
CANVAS_DIR = "C:\\Users\\wurde\\GitHub\\canvas"
I've read that I should avoid hard coding paths and instead use joins. Is that the best way? If so, how does that look implemented?
Looking at the File API in Ruby I think I have the a working join solution. The important bit was to include the home directory via environment variable.
CANVAS_DIR = File.join(ENV['HOME'], 'GitHub', 'canvas')
I need to write a small script that renames some files in a directory. This script needs to be run on Mac and Windows.
What is the best scripting language for this? I want to write something that runs just by calling it and there is no need to install anything else.
For example, writing a Perl script and compiling it to run on Windows and then compiling it to run on Mac. Can I do this?
Any other, more elegant solution?
Nothing matches your criteria. You will need to install something (e.g. perl) if you want something that runs on both systems.
If you had perl on both systems, you could indeed write a program that runs on both. You wouldn't even need two binaries as you suggest since Perl programs are distributed as source. (perl compiles them when it loads them, and even then, they are compiled to the same form on all systems.)
I am writing a small tool, that copies clipboard of linux into windows clip-board. Let me take an example, both linux and windows in network connection. I copy something in linux to clip-board, then when I press some keys in windows lets take CTRL+ALT+v what is copied in linux should print in linux.
What I thought is executing some script in linux from windows through ssh connection. That script shall copy the clip-board into some file in windows, then windows shall put the file content into windows clip-board.
My problem is connection with linux from windows and executing the script. How can I achieve this ?
And please share if you have any better idea to do this.
Thanks a lot :).
There is a free, cross-platform, open-source program called Synergy that does exactly what you are describing (and more), and I have tested it with a Windows/Linux connection. You could take a look at the source code and see how the clipboard functions are implemented, or it might fit your needs already.
I have a Win7 PC in use as part of an experiment control system. The experiment in question uses 4 windows simultaneously, and I would like to find away to open, position and size these 4 windows with a script.
The script would run at start up, so that the newly booted PC presents the user with the four windows as default.
Obviously I can use a batch file in the startup folder to open windows and run applications, but is there a way to specify the layout of these windows?
Many thanks
Si
Assuming that you have access to a scripting language that supports making calls to Windows API functions it shouldn't be too hard. Otherwise I'd suggest writing a small executable in some language (at least any of C++, C# or VB.Net would all work fine) and have that do it.
You could use FindWindow, as described here, to find the windows and MoveWindow, as described here, to move them around.
I use an AutoHotkey script to set up all my environment (around 7 windows in 3 different virtual screens), works pretty well. You can set the location of windows etc.
I can use a batch file to open the apps, then run WiLMA to relocate them
I remember a few years ago(2002) there was a multipartite virus that could be run natively on linux and windows. I don't know if a compiler could be specially craft an executable so that it could be read as both ELF and PE, so that the os would start executing at different entry points. Or a program that could merge two programs, one compiled using mingw, one compiled in native linux, to one program.
I don't know if such a program exists, or could it exist, and I'm know this could be implemented in Java or some scripting language, but that's not a native program.
Imagine the possibilities, I could deploy a program with linux and window (and perhaps os/x)libraries, and one main executable that could be run on any os. The cross-platform support would compensate the bigger size.
Windows programs have a DOS stub in the beginning, and I just ran an ELF executable through debug.com, which said that the first instruction of this exe was JG 0x147. Just maybe something could be done with this...
No.
Windows and Linux use vastly different binary file formats. See Portable Executable (Windows) and Executable and Linkable Format (Linux).
Something like WINE will run Windows executables on Linux but that's not the same thing.
This is actually a really terrible idea for multiple reasons.
Cross-compiling across operating system boundaries is extremely difficult to do properly.
If you go for the second route (building separate PE binaries on Windows and ELF on Linux, and then somehow merging them) you have to maintain two machines, each running a different OS and the full build stack, and you'd have to make sure that you tested both versions separately before gluing them together.
Dynamic linking is already a pain to properly manage, on Windows and on Linux; static linking can generate binaries that are much more inconvenient to deal with than whatever imaginary benefits you get from providing one single file type to your end-user.
If you want to run the same binary executable file on multiple OSes, your options are Java, Mono, and potentially NativeClient, the browser plug-in Google's developing to work around the "webapps are too slow" problem.