I have created an executable (.exe) of a perl script on a 64-bit linux kernel. It executes correctly in this environment.
When the executable is run in 64-bit Windows 7, the following error message is displayed:
The version of this file is not compatible with the version of Windows
you're running. Check your computer's system information to see
whether you need x86 (32-bit) or x64 (64-bit) version of the program,
and then contact the software publisher.
Given that the source and destination OS's were both 64-bit, I'm not sure that the architecture of the build is the issue. Are there any special considerations to make a compiled perl program execute properly in Windows? Thank you.
Executable files are not compatible across platforms. They will run on the original platform only unless they are explicitly cross-compiled to a different target. That's actually the reason we use interpreted languages. What you want to do is not possible because the Windows and Linux APIs, libraries, and well just about everything are completely different.
This is why you need to download a different version of a program for linux/windows/mac.
Related
I have a computer at work, and it does have Windows XP 32-bit OS and no Matlab.
And I wrote a code on Matlab on different computer(Windows-10 64-bit OS), and made a standalone application using Matlab's Application Compiler.
I got an .exe file for my program. I tried to run .exe file on Windows XP computer, but it gave an "invalid machine" error( I don't know what that means.)
Is there any way I can run this standalone application .exe on Windows XP? Is it because of 32-bit situation, or because of Windows XP?
And one last question, if I can't run .exe on Windows XP, to which program language should I convert my code? So I can run program on Windows XP 32-bit, Windows XP 64-bit, or for example Vista,Ubuntu etc.
Actually, which program language is compatible with all OS platforms? Is python compatible?
Thank you for reading, hope I did not take your time. Thanks in advance.
Link with Dynamic RTL=true
Compiler running under XP prompt error
Unable to locate the program input point acquiresrwlockshared on the dynamic link library kernel32.dll.
AcquireSRWLockShared() was introduced in Windows Vista. Clearly something in your project is static-linking to that function, so the error message makes sense when running your code on XP. Note also that you enabled the Dynamic RTL, but you did not also enable the Delphi Runtime Library, too. Typically, most C++Builder users disable these options to produce standalone executables, but you seem to want to enable them instead to utilize runtime BPLs (which will still fail to load on XP btw, even if your main EXE could run).
XP is no longer a supported platform. You can't run the IDE itself on XP, nor can you run programs compiled with 10.4 on XP. The IDE itself requires Windows 10 or later. Compiled programs require Windows 7 SP1 or later. See Operating System Requirements in 10.4's documentation.
The last version to officially support compiled programs running on XP was XE2. Support for XP was dropped in XE3.
I want to compile a customized Apache module for OHS on Solaris 64bit SPARC machine. It is a Apache C code. But what I have is only Windows machine and Linux VMs. Can this achieved using Oracle developer studio IDE. Or is there any other way? Please help
You can use QEMU and run a SPARC virtual machine under emulation:
Status
The table below gives the status of the SPARC machines available in
QEMU and is correct as of the latest release:
Machine Status
sun4m Complete, supported
sun4u Beta, supported
sun4v Incomplete, unsupported
niagara Complete, supported
Pay particular attention to the exact architecture you need to compile for. You should be able to run Oracle Developer Studio on the emulated system. You may have to use an older SPARC architecture to generate binaries runnable on your target systems. For example, you might want to use something like -xarch=sparcv9.
Note that the emulated system will be S-L-O-W. Large compiles can take hours or even days. You should probably develop your Solaris-specific code on an x86 VM, and only do the final SPARC compile on the emulated system. Just be aware that you can get away with strict aliasing and alignment violations on x86 systems that will throw a SIGBUS on SPARC systems.
I just installed GitHub for Windows on my 64-bit Windows 7 computer, and the GitHub always get the following two errors complaining about two components are 16-bit applications incompatible with the 64-bit Windows OS. The two error messages are attached below.
I think there should be many users running GitHub on 64-bit Windows, so could someone please provide some workaround for this issue?
1) The first error
Unsupported 16-Bit Application
The program or feature "\??\C:\Users\mikez\AppData\Local\GitHub\PortableGit_054f2e797ebafd44a30203088cd3d58663c627ef\bin\ssh-agent.exe" cannot start or run due to incompatibity with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.
2) The second error
Unsupported 16-Bit Application
The program or feature "\??\C:\Users\mikez\AppData\Local\GitHub\PortableGit_054f2e797ebafd44a30203088cd3d58663c627ef\bin\ssh-keygen.exe" cannot start or run due to incompatibity with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.
Give msysgit a try. I heard that this works fine.
I need to test my C code for 32- and 64-bit versions of Windows (XP and 7) and Linux. But I have got access only to their 64-bit installations.
Question: Is it possible to use some boot-time settings or other hacks to run/emulate these OSes in 32-bit mode? If not, is there any other way to test the portability of my C code?
Note: The C code in question is not a full-fledged application but rather a .dll/.so file.
Neither Linux nor Windows 64Bit can run as 32Bit OS. Also, while you can run 32Bit executables on the 64Bit OS, it is not quite the same as running the same under a 32Bit OS. But it might work as a quick screening test. Besides, you certainly want that to work as well, right?
Your choices are full multi-boot setup, using VMs (might hide/expose bugs), being content with the emulation layer or running the other OS's on different hardware.
BTW: If you have Windows 64Bit, the license allows you to run 32Bit instead and vice versa. Anyway, you might want to check different language versions as well...