Cannot execute binary file error - linux

I just a ran simple hello world program in my linux it worked perfectly.when i supposed to ran same file in the hand held device (running on the linux os)i got the error like Cannot execute binary file error.i am completely new to linux.
can anybody help me?

Just because the OS is the same does not mean an executable will run. The binary file is composed of machine instructions the processor can understand. Moving back and forth between processors with the compatible instruction sets will normally work fine, but if they are not compatible the CPU will not be able to understand the instructions.
Most Intel processors use a x86 ISA (instruction set architecture), that your mobile processor is likely not compatible with.

Just a heads up because I had this problem but the b4-bit application for 32-bit OS didnt work for me. If your in linux you probably need a gcc compiler on the backend of terminal that might not be installed. If you dont have this Linux doesnt seem to know how to read the file.

su <user-name>
Then command/file should be executed.

Related

How to debug windows executable in Linux

I am using Ubuntu 13.10. Is it possible to debug a windows executable under Linux?
I've tried gdb, but it always throw me this error message.
/bin/bash: line 0: exec: /some.exe: cannot execute: Permission denied
I don't have much experience with this but, I think, what you're looking for is winedbg. Initially, it should allow you to debug Win32 applications in Linux.
I suggest you try the IDA Debugger (cross platform debugger).Hope it helps.
You are trying to execute a program designed to run in a OS, from within another one, which could be using a complete different processor than a x86.
In order for a executable program to be run in a specific OS, these modules or services must exist:
A module that can understand the binary code of the executable program and translate, if needed, into binary code of the host processor.
A service that can intercept any instruction identified as a system call, and emulate its behaviour using host resources
A module that is able to load, parse and prepare a process block to acommodate the new "guest" process
This is just for executing a program. To debug it, you also need a service that can interact with the above mentioned modules/services in order to control execution of that program.
That said, you can probably debug an EXE file using some utility from the Wine project, asumming your Ubuntu is running on a x86 processor. Take a look at it.
http://www.winehq.org/
Also, I recall VirtualBox offers some sort of debugging help for processes running on the guest OS, but I'm not sure about this.
No, it is NOT possible to debug a Windows executable under Linux.

Native windows Linux

I know about several projects for cross compiling between linux and Windows.
The Wine project is great for running windows application inside Linux.
andLinux is a linux running inside Windows.
My question is, can we compile a complete linux OS with a Windows compiler (like mingw32, visual studio , ...) in order to get a linux system which is fully compatible with the Windows PE executable format ?
As wine demonstrates, the PE format isn't really the problem with compatibility.
PE only defines how the program is pieced together at load time. Under windows, RUNDLL interprets it, loads all the program sections to memory, loads all the supporting dlls to memory and patches up the function pointers so that there is a program sitting in memory ready to go. (See http://msdn.microsoft.com/en-us/library/ms809762.aspx for more details. Its a good read!)
There is little stopping you writing a kernel module to do all of this. With the details in the page linked above it may not be to hard and someone may already have done it.
The real issue is the fundamentals of the operating system. Even if linux could load a PE, there would be problems around the fundamental difference in file names (\ or /) as well as the permissions model which is different and the windows registry which doesn't exist under linux. That's before you get into the different windowing model for GUIs.
Therefore the task of getting a windows program to run under linux is less about the program loader and much more about emulating all of the windows DLLs under Linux. As i understand it, this is the main heart of wine.

DDK/WDM developing problem ... driver won't load on x64 windows platform

I am a beginner at DDK/WDM driver developing field.
I have a task which involves porting a virtual device driver from x86 to x64 (intel).
I got the source code, I modified it a bit and compiled it succesfuly with DDK (build environments). But when I tried to load it on a ia64 Windows7 machine it didn't want to load.
Then I tried some simple examples of device drivers from
--http://www.codeproject.com/KB/system/driverdev.aspx (I put '--' to be able to post the hyperlink) and from other links but still the same problem.
I hear on a forum that some libraries that you use to link are not compatible with the new machines and suggested to link to another similar libraries...but still didn't worked.
When I build I use "-cefw" command line parameters as suggested.
I do not have an *.inf file asociated but I'm copying it in system32/drivers and I'm using WinObj to see if next restart it's loaded into the memory.
I also tried this program ( http://www.codeproject.com/KB/system/tdriver.aspx ) to load the driver into the memory but still didn't worked for me.
Please please help me...I'm stuck on this and my deadline already passed.
I feel I'driving nuts in here trying to discover what am I doing wrong.
So, to summarize everything:
You need to build for the corect architecture (x64 for Intel/AMD CPUs).
You MUST sign your driver. You must do this even in test mode with a self signed certificate. There is no alternative.
You MUST use an .inf file to install. If the driver is non-pnp then you don't need an .inf file, but it is very unlikely that the driver is non-pnp. In that case you need to manually create the associated service for the driver in the service control manager with sc.exe or programmatically with the SCM API. If the driver isw pnp (most likely) you must install it via an .inf file (with devcon.exe or other way). Also, installing it is not the same as loading it. For that, the appropriate hardware must be present or you must enumerate it in software (with devcon.exe for exemple).
I did not wrote a driver, but on the basis on what I hear from colleagues: Are your driver digitaly signed? If not, look for information on loading unsigned drivers on 64bit systems.
Two things:
You mention both x64 (also called x86-64, AMD64, or EMT64) and IA64 (Itanium). You understand they are two completely different architectures, right? Do you have an Itanium System? If not, you should not be compiling anything using the IA-64 build environment. It won't run on a standard PC (32 or 64).
Under 64-bit, the driver must digitally signed for production use. You will need to get an Authenticode certificate from Verisign or similar. For testing purposes, you can bypass the signature check by pressing F8 at boot time. You can also sign with a test certificate.
http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx

How do I compile mips gnu?

I am not even sure my thread title is correct or not. Here is my story. I visited western digital website to check for a new firmware of wdtv live. I found source code of wdtv live OS is available to download. I downloaded "WDTV GPL Code" on http://support.wdc.com/product/download.asp?groupid=1003&lang=en. I extracted it and...came up with
mips-4.3.tgz
linux_kernel_2.6.22.19-19.tgz
I googled about those two archive and I guess "mips-4.3.tgz" is operating system and "linux_kernel_2.6.22.19-19.tgz" is linux kernel obviously.
In my understanding, I need to have a running linux in order to compile linux kernel. So I assume that I have to install mips-4.3.tgz somehow.
Does anyone have any idea on how to install mips??
While these instructions seem to be geared towards the Android, maybe they can be of some use.

Cross Compiling Linux Kernels and Debugging via VMware

I'm considering doing some Linux kernel and device driver development under a vmware VM for testing ( Ubuntu 9.04 as a guest under vmware server 2.0 ) while doing the compiles on the Ubuntu 8.04 host.
I don't want to take the performance hit of doing the compiles under the VM.
I know that the kernel obviously doesn't link to anything outside itself so there shouldn't be any problems in that regard, but
are there any special gotcha's I need to watch out for when doing this?
beyond still having a running computer when the kernel crashes are there any other benefits to this setup?
Are there any guides to using this kind of setup?
Edit
I've seen numerous references to remote debugging in VMware via Workstation 6.0 using GDB on the host. Does anyone know if this works with any of the free versions of VMWare such as Server 2.0.
I'm not sure about ubuntu thing. Given that you are not doing a real cross compilation (i.e. x86->arm), I would consider using make-kpkg package. This should produce an installable .deb
archive with kernel for your system. this would work for me on debian, it might for for you
on ubuntu.
more about make-kpkg:
http://www.debianhelp.co.uk/kernel2.6.htm
I'm not aware of any gotchas. But basically it depends what kind of kernel part you
are working with. The more special HW/driver you need, the more likely VM won't work for you.
probably faster boots and my favorite is the possibility to take screenshot (cut'n'paste) of panic message.
try to browse to vmware communities. this thread looks very promising, although it dicusses
topic for MacOS:
http://communities.vmware.com/thread/185781
Compiling, editing, compiling is quite quick anyway, you don't recompile you whole kernel each time you modify the driver.
Before crashing, you can have deadlock, bad usage of resource that leads to unremovable module, memory leak etc ... All kind of things that needs a reboot even if your machine did not crash, so yes, this can be a good idea.
The gotchas can come in the form of the install step and module dependency generation, since you don't want to install your driver in the host, but in the target machine.

Resources