Running C Built .exe On Another PC

Question

I've built a programme in C with Visual Studio using standard C libraries + a couple of windows libraries.

The code just acquires user input (with scanf, so through cmd window) does some calculations based on the input and outputs some text files, that's about it.

I'm wondering what would I then need to do to run my exe on another standard Windows computer without it needing to install any additional files e.g. the whole Windows SDK.?

Is it just a case of being able to build the release version (as opposed to the debug)?

Many thanks

Answer 1

I've built a programme in C with Visual Studio using standard C libraries + a couple of windows libraries.

I'm wondering what would I then need to do to run my exe on another standard Windows computer without it needing to install any additional files e.g. the whole Windows SDK.?

You don't explain what your program is really doing. Does it have a graphical user interface? Is it a web server? Do you have some time to improve it or enhance it? Can it run on the command line?

Why cannot you share the C source code (e.g. using github)?

If you want some graphical interface, consider using GTK. It has been ported to Windows.

If a web interface is enough, consider using libonion in your program, or find some HTTP server library in C for your particular platform.

But what you need understand is mostly related to linking, not only to the C programming language (read the n1570 specification). Hence read about Linkers and loaders.

You should prefer static libraries. Their availability is platform specific. Read more about Operating Systems. Also, sharing some Microsoft Windows system WinAPI libraries could be illegal (even when technically possible), so consult your lawyer after showing him the EULA that you are bound to.

My opinion is that Linux distributions are very friendly when learning to program in C (e.g. using GCC or Clang as your C compiler). Both Ubuntu and Debian are freely downloadable, but practically require about a hundred gigabytes of consecutive free disk space. Be sure to backup your important data before installing one of them.

Did you consider porting, adapting and compiling your C code to WebAssembly? If you did that, your code would run inside most recent Web browsers. Look also into Bellard's JSLinux.

Related answer here. Notice that C can be transpiled to JavaScript and then run locally inside recent web browsers.

Answer 2

If you pick the right CPU target (Project Configuration Properties -> C/C++: Enable Enhanced Instruction Set) such that the binary code doesn't include instructions understood by only a very narrow subset of CPUs, and the default for Visual Studio is to use instructions that are supported by the widest set of x86 or x64 CPUs, then your program will run on almost any Windows computer. You need to distribute any DLLs that aren't part of the base Windows installation though, which includes any additional dynamically linked language runtimes such as the Visual C++ runtime.

A good way to derive the list of DLLs that you have to package with your executable is to create a virtual machine with a fresh Windows installation without any development tools in it and then try to run your code there. If you get an error for a missing DLL, add it and repeat. When it comes to the Visual C++ runtime, Microsoft provides installable packages for the different versions that you are allowed to distribute as part of your installation (Visual C++ Whatever Redistributable Package).

Also, mind that programs compiled for 32-bit Windows will mostly run on 64-bit versions, but the opposite is not true.

Answer 3

Generally speaking, C programs are not "portable" meaning they can't be copied over to other machines and expected to run.

There are a few exceptional cases where C executables can safely be ran on other machines:

1. The CPUs support the same instruction set, with the same set of compatible side-effects and possibly the same bugs.
2. The Operating systems support the same system api points, with the same set of compatible side-effects and possibly the same bugs.
3. The installed non-operating system libraries support the same api points, with the same set of compatible side-effects and possibly the same bugs.
4. The API calling conventions are the same between the source (platform you built the code on) and destination (platform you will run the executable on).

Of course, not all of the CPU and OS need to be 100% compatible, just the parts your compiled program uses (which is not always easy to see as it is compiled, and not a 100% identical representation of the source code)

For these conditions to hold, typically you are using the same release of the operating system, or a compatibility interface designed by the operating system packagers that supports the current version of the operating system and older versions too.

The details on how this is most easily done differ between operating systems, and generally speaking, even if a compatibility layer is present, you need to do adequate testing as the side-effects and bugs tend to differ despite promises of multi-operating system compatibility.

Finally, there are some environments that can make non-same CPU executables run on an operating system (like QEmu) by simulating the foreign CPU instruction set at runtime, interperting those instructions into ones that are compatible with the current CPU. Such systems are not common across non-Linux operating systems; and, they may stumble if the loading of dynamic libraries can't locate and load foreign instruction set libraries.

With all of these caveats, you can see why most people decide to write portable source code and recompile it on each of the target platforms; or, write their code for an interpreter that already exists on multiple platforms. With the interpreter approach, the CPU is conceptually a virtual one, which is implemented to be identical across hardware, letting you write one set of source code to be interpreted across all the hardware platforms.