I am currently evaluating List & Label. The edition comparison seems to indicate that the Standard edition cannot be used by 64-bit programs, and I also got that confirmed by the company making the product. However, what I need to know is the following.
I plan to use List & Label in a Visual Studio solution with projects compiled for AnyCPU with "Prefer 32-bit" set.
Is there anybody out there that runs the licensed Standard edition with AnyCPU and "Prefer 32-bit" set on a 64-bit machine? It would be nice to know for certain whether it works or not.
Yes, this will work. See What AnyCPU Really Means As Of .NET 4.5 and Visual Studio 11 to confirm this will start a 32 bit process on all platforms supported by List & Label:
If the process runs on a 32-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
If the process runs on a 64-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
Related
I'm working to install the Crystal Reports Runtime (SP31) on a Windows Server 2016 machine, and I just wanted to know - is there anything special I need to know about the installation process? Any special steps that are needed that are different from installing on a local user machine? Any known issues?
Just remember that the choice of 32-bit vs 64-bit is NOT based on the platform. Even if the machine is 64-bit, you should still install the 32-bit version if your app was compiled for 32-bit.
Similarly, data connectivity (e.g. ODBC) should be 32-bit if the app was compiled for 32-bit.
Also, be aware that if the machine has another application that uses the Crystal runtime, but from another service pack, you might run into conflicts.
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 am trying to do some embedded programming for an online course. The IDE I had to use does not have a Linux version, so I am planning to use the ARM DS-5. It says it can be used with eclipse but I cannot figure out how to get them to work. I have Ubuntu 14.04. I read somewhere that the ARM-DS-5 wouldn't work with anything newer than indigo but that was from 2012 and am not sure how accurate that is now. Any help would be great.
Depending on the use-case, you can pick one the three DS-5 variants.
Community Edition
Free to use.
Allows Linux library/app debug using GNU tools.
Comes in two flavors - Eclipse Plugin and Full Fledged IDE.
Professional Edition
30 days free evaluation.
Allows bare-metal (no OS) and Linux kernel and app debug.
Comes with ARM compiler, debugger along with GNU tools.
Comes with FVP, ARM's virtual hardware, allowing development without real hardware.
Ultimate edition
Everything in the Professional edition plus support for ARMv8, the ARM's architecture with 64-bit support.
You can visit here to see more detailed difference between various editions.
Note there is only one DS-5 IDE installer, which is available for download here. The variant is decided based on type of license chosen. So if you download DS-5 Ultimate for 30-day eval, it can converted to Community edition by changing the license at the end of eval period.
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...
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.