Need help with standalone app using VS

[denver2020]

I need to make a standalone .EXE file from visual studio 2019 that needs to be deployed or installed on a new machine that does not have Visual Studio or any C/C++ compiler at all. How can I do this? Any idea? I have tried to copy the .EXE file obtained in the "release" folder within the application project in VS, on to the other machine but it's not working.

[denver2020]

Do I need to statically link DLLs (which are application dependent) into my EXE, so that it becomes fully stand alone? How to do this in vs 2019?

[JLBorges]

We can include Visual Studio's redistributable DLLs with our installer.

More information: https://docs.microsoft.com/en-us/cpp/windows/determining-which-dlls-to-redistribute?view=msvc-160

[denver2020]

If I try to launch my EXE file by commandline, it doesnt get launched. No errors are seen in commandline window, after I added the SDL DLL's in the same project folder as that of my EXE in "release" folder. While I open EXE file in DependencyWalker, I can see it requires one or few DLLs but Win32 DLLs. My application EXE uses some third party DLL's (SDL library DLL used here) which are not supplied by VS 2019.

There is a big list of DLL...below are a few. It says Error opening file. The system cannot find the file specified. I use Windows 10 OS and I dont know where to find these DLL's?


API-MS-WIN-CORE-APIQUERY-L1-1-0.DLL
API-MS-WIN-CORE-APIQUERY-L1-1-1.DLL
API-MS-WIN-CORE-APIQUERY-L2-1-0.DLL
API-MS-WIN-CORE-APPCOMPAT-L1-1-0.DLL
API-MS-WIN-CORE-APPCOMPAT-L1-1-1.DLL
API-MS-WIN-CORE-APPINIT-L1-1-0.DLL
API-MS-WIN-CORE-ATOMS-L1-1-0.DLL
API-MS-WIN-CORE-COMM-L1-1-0.DLL
API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
API-MS-WIN-CORE-CONSOLE-L1-2-0.DLL
API-MS-WIN-CORE-CONSOLE-L1-2-1.DLL
API-MS-WIN-CORE-CONSOLE-L2-1-0.DLL
API-MS-WIN-CORE-CONSOLE-L2-2-0.DLL
API-MS-WIN-CORE-CONSOLE-L3-2-0.DLL
API-MS-WIN-CORE-CRT-L1-1-0.DLL
API-MS-WIN-CORE-CRT-L2-1-0.DLL
API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
API-MS-WIN-CORE-DATETIME-L1-1-1.DLL
API-MS-WIN-CORE-DATETIME-L1-1-2.DLL
API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
API-MS-WIN-CORE-DEBUG-L1-1-1.DLL
API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
API-MS-WIN-CORE-DELAYLOAD-L1-1-1.DLL
API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
API-MS-WIN-CORE-ERRORHANDLING-L1-1-2.DLL
API-MS-WIN-CORE-ERRORHANDLING-L1-1-3.DLL
API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
API-MS-WIN-CORE-FIBERS-L2-1-0.DLL
API-MS-WIN-CORE-FIBERS-L2-1-1.DLL
API-MS-WIN-CORE-FILE-L1-1-0.DLL
API-MS-WIN-CORE-FILE-L1-2-0.DLL
API-MS-WIN-CORE-FILE-L1-2-1.DLL
API-MS-WIN-CORE-FILE-L1-2-2.DLL
API-MS-WIN-CORE-FILE-L2-1-0.DLL
API-MS-WIN-CORE-FILE-L2-1-1.DLL
API-MS-WIN-CORE-FILE-L2-1-2.DLL
API-MS-WIN-CORE-FILE-L2-1-3.DLL
API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
API-MS-WIN-CORE-HEAP-L1-1-0.DLL
API-MS-WIN-CORE-HEAP-L2-1-0.DLL
API-MS-WIN-CORE-HEAP-OBSOLETE-L1-1-0.DLL
API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
API-MS-WIN-CORE-IO-L1-1-0.DLL
API-MS-WIN-CORE-IO-L1-1-1.DLL
API-MS-WIN-CORE-JOB-L1-1-0.DLL
API-MS-WIN-CORE-KERNEL32-LEGACY-L1-1-0.DLL
API-MS-WIN-CORE-KERNEL32-LEGACY-L1-1-1.DLL
API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-0.DLL
API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-2.DLL
API-MS-WIN-CORE-LARGEINTEGER-L1-1-0.DLL
API-MS-WIN-CORE-LIBRARYLOADER-L1-2-0.DLL
API-MS-WIN-CORE-LIBRARYLOADER-L1-2-1.DLL
API-MS-WIN-CORE-LIBRARYLOADER-L1-2-2.DLL
API-MS-WIN-CORE-LIBRARYLOADER-L2-1-0.DLL
API-MS-WIN-CORE-LOCALIZATION-L1-2-0.DLL
API-MS-WIN-CORE-LOCALIZATION-L2-1-0.DLL
API-MS-WIN-CORE-LOCALIZATION-OBSOLETE-L1-2-0.DLL
API-MS-WIN-CORE-LOCALIZATION-PRIVATE-L1-1-0.DLL
API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
API-MS-WIN-CORE-MEMORY-L1-1-1.DLL
API-MS-WIN-CORE-MEMORY-L1-1-2.DLL
API-MS-WIN-CORE-MEMORY-L1-1-3.DLL
API-MS-WIN-CORE-MISC-L1-1-0.DLL
API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
API-MS-WIN-CORE-NAMEDPIPE-L1-2-1.DLL
API-MS-WIN-CORE-NAMEDPIPE-L1-2-2.DLL
API-MS-WIN-CORE-NAMESPACE-L1-1-0.DLL
API-MS-WIN-CORE-NORMALIZATION-L1-1-0.DLL
API-MS-WIN-CORE-PATH-L1-1-0.DLL
API-MS-WIN-CORE-PCW-L1-1-0.DLL
API-MS-WIN-CORE-PRIVATEPROFILE-L1-1-0.DLL
API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-2-0.DLL




Error: At least one required implicit or forwarded dependency was not found.
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

[Duthomhas]

The other PC is a 32-bit OS? And yours is 64-bit?

[deleted account xyzzy]

denver2020 wrote:

I open EXE file in DependencyWalker

Oh, ICK! DW is years out-of-date and will never get fixed, you shouldn't use it.

Use "Dependencies" instead.

https://github.com/lucasg/Dependencies

[deleted account xyzzy]

Dependencies should resolve where those missing API-MS DLLs are. They are "hidden" within other DLLs.

For example (x86 compiled app):
api-ms-win-crt-runtime-l1-1-0.dll -> C:\WINDOWS\SysWOW64\ucrtbase.dll

The same app compiled as x64:
api-ms-win-crt-runtime-l1-1-0.dll -> C:\WINDOWS\system32\ucrtbase.dll

[denver2020]

Is this due to symbol files not being loaded properly?

[JLBorges]

> Error: Modules with different CPU types were found.

This seems to be an architecture (X86/X64/ARM64) mismatch.

In addition, "the version of the Microsoft Visual C++ redistributable installed on the machine must be the same or higher than the version of the Visual C++ toolset used to create your application".
https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-160

[denver2020]

Actually I did a 32bit build on my 64 bit machine. is this creating all these issues?
I never used "Dependencies" before. Is there any other way to extract DLLs from EXE file?

[deleted account xyzzy]

All that Dependency Walker/Dependencies does is show what DLLs are used/needed by the app. The DLLs themselves are NOT linked into the app as if they were a resource.

DLLs are used so common code is not linked into an app's executable. To reduce the file size.

If you linked all the code from the Windows DLLs the file size would be GINORMOUS.

The Desktop WinAPI is not an easy beast to grasp without a lot of time and effort expended. The Microsoft Foundation Classes (MFC) were created as a C-based means to leverage the C-based means and methods of dealing with Windows. Most times a very thin layer or veneer, sometimes an encapsulation that hides a lot of the "how does this work." Yet properly using MFC is just as much an learning investment as delving into the Desktop WinAPI.

And I ain't talking about what 3rd Party/later MS additions bring to the table. Like SDL, GDI+, DirectX, Common Controls, COM, etc. Or .NET/UWP.

The differences between how Petzold shows how to create WinAPI in his 5th Ed. book vs. his 6th Ed. book is very stark. C vs. C#/.NET, etc.

denver2020, you might consider stepping back and try learning/relearning the WinAPI from the beginning. Charles Petzold's "Programming Windows, 5th Edition" might be a good place to start. Old, but I'd say a lot of the issues you are having would disappear or become easier to understand and correct.

The code on the 5th Ed.'s CD won't compile or run properly now in 2021, especially when compile with MSVC. The API has changed significantly, along vast changes to Windows itself. Win9x/Me are dead, dead, dead. 16-bit processors are just as dead. Petzold's 5th Edition was written when Win98 was still around.

Luckily someone has updated a lot of the code so modern compilers won't puke all over the code.

https://github.com/recombinant/petzold-pw5e

I going back and plowing my way to the updated code, and tweaking it for creating Unicode-only executables. x86 and x64. ANSI is another Win9X/Me legacy that deserves to die and go away.

VS 2022, currently(?) in beta test, will only run on x64 machines. VS 2019 can be installed on x86 machines, able to create both x86/x64 .exes.

Can VS 2022 still create x86 apps? Yes it can.

https://devblogs.microsoft.com/visualstudio/visual-studio-2022/

[Duthomhas]

OP has an architecture mismatch, but doesn’t seem to want to accept that as an answer.


You do not ever need to play with the DLLs in any directory under C:\Windows. Those are specific to the machine and if you manage to dink with them you’ll hose your user’s system, and your user will loathe you with the hatred of a thousand suns.

All you need are the Microsoft redistributables and the SDL DLLs. Put all the DLLs in the same directory as your EXE and zip it up for your users to unzip. (If this is something you wish to distribute generally, create an installer. InnoSetup is a good choice for that.)

[deleted account xyzzy]

InnoSetup is a good choice

I gotta agree with that. Free (YAH!), and (relatively) easy to script an install. Comes with some sample scripts too. Definitely something to consider for a no-brainer Win install.

About the only thing IMNHO missing is some form of a GUI interface. But that would likely cost. Free is good.

[deleted account xyzzy]

I added the SDL DLL's in the same project folder as that of my EXE in "release" folder.

If you are using SDL2 you don't need to do that, you can statically link SDL.

https://wiki.libsdl.org/Installation (scroll down, read the entire page. There's lots of VS/Win info)