On http://caml.inria.fr/download.en.html I can only find the version 3.11.0 for Windows 32. Is there a precompiled OCaml 3.12.0 for Windows 64?
To provide a tidbit of information that could also have been provided there (but wasn't), there are roughly three categories of supported targets for the OCaml compilers.
In the first category, common architectures, binaries are provided by INRIA: Windows 32-bit, Linux, Mac OS X.
Targets platforms in the second category are those for which they have one installation. INRIA OCaml developers can reproduce bugs specific to that platform if you report them, but none is using the platform as its main development platform, and it would be too much work for them to release binaries for all platforms in this category.
Target platforms in the third category are those they do not have immediate access to.
64-bit Windows is a second-tier platform.
Related
I'm working on a game using C++ and relying on legacy features of OpenGL.
I've mostly been doing programming on Windows machines and am now looking into expanding into Linux and Mac OS. As a personal challenge, I'd like to keep my software as backwards-compatible as possible and support as many OSes as possible. With Windows, I've been able to upkeep support for as low as Windows 95 (with Visual Studio giving me some trouble in the process but working it out nevertheless). However, I have next to no knowledge of Mac OS, having never used it myself until just now. Considering my software runs on Windows 95, it certainly does not require any advanced features on functions.
The lowest version of Mac OS that old versions of Xcode seems to support is 10.1.x. If I was to write software for this version of Mac OS, would it run on more modern versions of Mac OS? I've read that there are software patches that enable support for some older MacOS software on never versions but I would rather not inconvenience the end user like that.
I would not mind building two different versions of the software (say, a legacy and modern launcher) but having to build five or ten different versions of the software would be a massive pain and I'd rather avoid that if at all possible.
I apologize for my lack of knowledge in the field, my own research has only yielded very limited information and I would rather not waste weeks on a fruitless endeavor.
TL;DR: I want to write software in Xcode (C++) for Mac OSX that supports as many versions of the OS as possible. If I was to target Mac OS version 10.1, can I expect it to run on modern versions of Mac OS? If not, how much effort would it take to support as many versions of Mac OS as possible?
You're going to have to make a decision as to where you're going to cut off support, or you're going to have to build multiple versions of the app in different specially-built build environments.
Modern macOS (10.15) is strictly 64-bit x86-64 only, zero support for 32-bit apps. If you build on 10.15 you can't even build a 32-bit image. If you did it would be linked against libraries that don't exist on older versions of the OS.
Mac OS X 10.6 was the last 32-bit x86 version that shipped, but was also the first 64-bit version of the OS, as it represented the transition to 64-bit. It was also the last PowerPC version that shipped.
If you want to support PowerPC machines, which was the only option in the 10.1 days, you'll need a compatible system to build it.
Ecosystem-wise, most Mac users are able to run current versions of the OS. Anything 2012+ is still able to get current OS releases, which is a lot of hardware. Anything before that is a mix of 32-bit and PowerPC hardware, though you won't see a lot of people with systems like that in the wild.
In short, 10.15 is easy, 10.14 and 10.13 aren't going to be hard. Anything beyond that will be various degrees of challenging, but beyond 10.6 things will get super complicated.
One way to estimate popularity is things like the Steam Hardware Survey where the breakdown looks like this:
10.15: 31.6%
10.14: 34.1%
10.13: 14.8%
10.12: 5.7%
10.11: 3.7%
So the good news is things drop off pretty steeply after 10.13 and by 10.11 there's not many users running an OS that old.
I am compiling a dll in visual studio 2017 c++.
SDK: 10.0.17134.0
this project uses a template, that automatically creates 2 dll, one for 32 bit and one for 64 bit. I do have two machines that run the same software but have different hardware and OS.
First machine has a intel i7 and runs windows embedded standard 64 bit
the second machine has a intel atom and runs windows embedded standard 32 bit
On the 64 bit machine, both dll work. (32 bit and 64 bit), on the atom the 32 bit does not work tough. I do not have any error messages, the only thing i get from the software is that it is not compatible without any additional clues. The software is the same on both systems so I assume that the problem is related to the OS or the processor.
the software I am developing for is a vision system by omron so it is nothing that is available online or that can be shared here.
What could be the cause for this? If you need additional information just ask.
Generally, in order for an executable file (either an .EXE program or a .DLL support module) built using the MSVC C/C++ compiler in Visual Studio 2015 or later, to work on a target PC, you need to have the latest VC++ Redistributable run-time libraries installed on that PC.
See also this discussion on Stack Overflow.
I am developing a cross-platform application and I need to determine whether machine B will be able to run the application that is compiled on machine A.
I am using Qt and I already understand that I need to either package the Qt libraries with the application or statically link against Qt itself.
I also understand that something compiled on Windows can't run on Linux.
However, there are still some other vectors that I'm not sure to what extent they matter. Here is the summary of my current understanding:
Affects Portability
Operating System (Windows, Mac, Linux)
Availability of third party libraries (Qt, static vs dynamic linking, etc)
May Affect Portability
Flavor of Linux (Ubuntu, Red Hat, Fedora)
Architecture (32 or 64-bit)
Version of Operating System (Windows 7 vs Windows XP, Rhel5 vs Rhel6)
Instruction type (i386, x64)
Of the May Affect Portability items, which ones actually do? Are there any that I am missing?
All. At least potentially.
If two different machines have no binary compatibility (e.g.
they run on different architectures, or interface to
incompatible systems), then it will be impossible to create
a single binary that will run on both. (Or... does running
a Windows program under Wine on Linux count?)
Otherwise, it depends. You mention third party libraries: if
they're dynamically loaded, they have to be there, but there's
always static linking, and there may be ways of deploying with
the dynamic library, so that it will be there.
The 32 bit vs. 64 bit is a difference in architectures: a 32 bit
program will not run in a 64 bit environment and vice versa.
But most modern systems will make both environments available
if they are on a 64 bit machine.
Issues like the flavor and version of the OS are more complex.
If you use any functions recently added to the OS, of course,
you won't be able to run on machines with an OS from before they
were added. Otherwise: the main reason why the low level system
libraries are dynamically loaded is to support forwards and
backwards compatibility; I've heard that it doesn't always work,
but I suspect that any problems involve some of the rarer
functions. (There are limits to this. Modern Windows programs
will not run under Windows95, and vice versa.)
There is also an issue as to whether various optional
packages are installed. Qt requires X Windows under Linux or
Solaris; I've worked on a lot of Linux and Solaris boxes where
it wasn't installed (and where there wasn't even a display
device).
And there is the issue whether it will run acceptably. It may
run on a smaller, older machine than the one on which you tested
it, but it could end up paging like crazy, to the point where it
becomes unusable.
If you compile an application on a 64-bit processor, it wouldn't by default run on a 32-bit processor. However, you can pass options to the compiler to have it compile code to run on a 32-bit processor. For example, if you're using GCC on a 64-bit machine, if you pass -m32, it will compile 32-bit code. 32-bit code by default can run on a 64-bit machine.
Sources
https://stackoverflow.com/a/3501880/193973
Different flavors of Linux or versions of operating systems may have different system libraries. For example, the GetModuleFileNameEx function is only available in Windows XP and up. As long as you watch what functions you use though, it shouldn't be too much of a problem.
The x64 architecture is backwards compatible with x86 ("32-bit"), so programs compiled for the x86 will run on x64 machines, but not vice versa. Note that there are other, less common architectures too, such as the ARM and PowerPC.
I can immediately think of three things that interfere with portability. But if your code is in a file format understood by both systems, an instruction set understood by both systems, and only makes system calls understood by both systems, then your code should probably run on both systems.
Executable File format
Windows understands PE, COFF, COM, PEF, .NET, and others
Linux by default ELF, OUT, and others
MaxOSX uses Mach-O
Linux has extensions to run the Windows/Mac formats too (Wine, Mono...)
Instruction set
Each processor is a little different, but
There is usually a "lowest common denominator" which can be targetted
Sometimes compilers will write code to do a function twice
one with the LCD set, one with a "faster" instruction set
and the code will pick the right one at runtime.
x64 can run 64bit and 32bit, but not 16bit.
x86 can run 32bit and 16bit, but no 64bit.
Operating System calls
Each OS usually has different calls
This can be avoided by using a dynamic library, instead of direct OS calls
Such as... the C runtime library.
Or the CLR for .Net.
Building a Windows 8 app, developers can choose HTML/JavaScript, XAML/.Net (C#/VB), and XAML/C++. I want to write my app in XAML/C++.
Building applications in the first two choices almost guarantees that your application will execute on both Intel and ARM architectures.
But I have heard that if I do certain things in my C++ app, I can cause the application NOT to execute on the ARM architecture. But I don't know the details.
Does anyone know what C++ Windows 8 apps should avoid so that they can run on ARM okay? Are these architecture decision or just differences in technique?
In order to run on each architecture you first need to compile for each architecture obviously. If you write standard C++ (and if you do not rely on undefined behaviour and/or platform specific behaviour) you are fine the things that usually cause troubles when porting between architectures is:
(this list is an example)
sizes of int, long, long long (and others) can differ between platforms
signedness of char
how structures are padded
binary layout of floats
endianess
and more so on.
Usually you are safe if you refrain from crazy pointer arithmetic and casting.
I'm not aware of anything that will make your code simply not execute or compile under ARM (other than inlining assembly).
However, there are things you can do which will make ARM give the wrong answer.
ARM processors are "weakly-ordered" this recent article gives you the low down
http://preshing.com/20121019/this-is-why-they-call-it-a-weakly-ordered-cpu
But to sum up, ARM processors may reorder memory accesses, and if you aren't careful, this can give you different results between x86 and ARM architectures in multi-threaded applications.
ARM is only supported for Windows Store apps.
System Requirements
Supported Architectures: The Windows SDK for Windows 8 supports
building applications for the following architectures: x86 x64 ARM
(Windows Store apps) Note: The Windows SDK for Windows 8 cannot be
installed directly on the ARM architecture. You can install the
Windows SDK on an x86 or x64 platform, in order to build applications
that target the ARM architecture.
Here is a link to the article that you can refer to.
MFC applications will not run on ARM based Windows 8 systems .
You can build Metro style applications using C++ , you just have to follow the Metro "style" guidelines.
Change your program to use HTML/CSS or XAML and the WinRT APIs instead of MFC and the Win32 APIs if you want all of your program to support ARM based Windows 8 systems as well as x86 based systems.
It is said that by using C/C++, one can write 'native' programs - that run on the platform. I am confused about what is considered native - the processor architecture or the OS version?
For example:
I have a 32 bit processor and Windows 7 ( 32 bit ), and I compile and generate and .exe file. Is it guaranteed to run on any Windows 7 32 Bit? ( Win 7 32 bit on 32/64 Bit machines )
Edit1:
I did not intend only Windows OS here. My example can be extended to Linux also. For example, generating an executable ( by default a.out ) on a 32 bit Linux OS running on 32 bit processor, and then running it on a 32bit Linux on a 64 bit processor.
Edit2:
Thanks for the responses, but I also intended that I am using the standard libraries and functions - nothing OS Specific. Just the once specified by the ANSI or ISO C++ Standard. No references to OS specific windowing systems or other libraries.
Thanks
Both; kind of.
The actual instructions don't really differ across Windows and Linux as they are compiled down for a single CPU architecture (x86).
However, a binary is more than just code that runs on bare hardware. For instance, it also contains information that tells the operating system how to load the executable and its dependencies. The binary is packaged in a specific format. This format can be different in different operating systems.
Besides that, the operating system provides some services to the applications (through system calls and APIs). The services that operating systems provide, and the way they can be used varies from an operating system to another.
These reasons contribute to the fact that most of the time a native binary depends on both OS and CPU architecture it's compiled for.
Answer to the updated question:
C++ Standard doesn't require anything about the nature of the compiled target. It just specifies compatibility requirements at the source level. Consequently, if you stick to the standard libraries, you'll be able to use the same source code to compile on platforms that offer a conforming C++ implementation. The standard doesn't say anything about binary portability. As I mentioned above, the primitive system calls that operating systems provide can vary and the actual implementation of the standard library depends on the way those system calls are provided by the OS.
In order to run a Windows binary on Linux, you need to use some sort of emulation like Wine which understands Windows binary format and simulates Windows API for applications.
1) The processor architecture (plus the targeted libraries static or dynamic)
2) Yes
A 32bit windows application will run on a Windows 64bit platform as WOW.
If your (windows) compiler's target architecture is x86 (32-bit) then it can run on any 32 bit and 64 bit Windows 7. But if its x86-64, it will only run on 64 bit Windows 7.
To answer the title specifically, you code for both.
The executable contains machine code, which is specific to the processor, and a lot of metadata for the OS on how to load/execute the program, which is specific to the OS.
The code may also (and typically does) contain calls into functions defined by the OS. And so, while it is just perfectly ordinary machine code that any compatible CPU will understand, it attempts to call code that only exists on Windows.
So "native" really means both. You code for the specific OS (and all compatible OS'es) and that specific CPU (and all compatible CPUs).
In the case of Windows, you typically target a specific version of Windows, and the program will then work on that, and future versions of Windows.
for the processor on which Windows (and your program) runs, the executable contains x86 machine code, which can be executed on any x86 CPU, whether it is from Intel, AMD, Via or whoever else have made compatible processors over the years.
Without being able to see your code, only you can tell us whether you're coding for 32-bit or 64-bit platform - for example, if you reinterpret_cast a pointer into a 32 bit int then back to a pointer, you are coding for 32-bit, whereas if you use a type such as int_ptr you are safe whether your code is compiled for 32 or 64 bit machines. Similarly, coding for Windows desktops your coding can assume the machine's endianess.
If, as in your example, you compile that code for 32-bit Windows 7, then it will also run on 64 bit Windows 7. If you use Windows 7 features, it won't run on earlier versions. Microsoft are very good at backward compatibility, so it probably will run on later versions.
Short answer: No.
Longer: When you compile "native code", you compile for a specific processor architecture; MIPS, ARM, x86, 68k, Sparc and so on. These architectures can have a wordlength of 8, 16, 32 and 64 (there are exceptions). Also these architectures can have extensions from generation to generation like MMX, SSE, SSE2, Neon and such.
Also you need to consider the operating system and what libraries you can use, and different calling conventions.
So, there's no guarantee. But if you compile with MSVC on Windows 7 it's almost guaranteed to run on Windows 7. I think it only exist for x86 at the moment.