Deploying Gstreamer 1.0 for Win32 - c++

I have successfully compiled a project with the SDK of 1.5.2. I took that application and the dlls to another machine, and it said it was not a valid Win32 application.
I compiled on a Win64 OS. Am I supposed to install Gstreamer on the other machine to run this application, or am I missing some dlls?
I have uninstalled Gstreamer from the computer I compiled it on, and ran the application with no problems, but when I run it on another machine it said not valid Win32 application.
Application compiled on Windows 7 64-bit.
Application target to run on Windows XP 32-bit.

I found out that in visual studio 2012 update 4 I need to select a few things to make it work.
Project Properties
1. Configuration Properties -> Linker -> System -> Left Windows on top under SubSystem select Console or Windows
2. Configuration Properties -> General -> Left window under Platform Toolset select "Visual Studio 2012 - Windows XP (v110_xp)"

Use Dependency-walker to check for required but missing DLL dependencies on the machine you want to deploy to.
Typically, you are missing the required C++ redistributable runtime for your specific Visual Studio version on the target machine.

Related

Why do I get "Illegal Instruction" error when Building on windows10 and running on Windows7

I have a c++ program built using VS2017 on windows7.
When I run it on Windows7 or windows10 there is no problem.
If I Build the same program on Windows10 (still using VS2017) the program runs OK on Windows10 but when I try to run it on Windows7 I get an "0xC000001D: Illegal Instruction." error.
Is it even possible to run programs built in Windows10 on Windows7 ? and if so what can I do?
Thanks
The default SDKs will be different on your two VS2017 installations. Right-click the project, select "properties", then the "General" page. See Windows SDK Version.
You can install different SDK versions (and different Platform Toolsets) using the Visual Studio installer ("Modify").
You would probably need to install the v140 toolset.
Also see the response here:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/e19634d8-f635-4ed0-b8d7-45b64ccbd6fa/windows-sdk-7-in-visual-studio-2017?forum=visualstudiogeneral
...which states:
You can create a project with the default project template. After that, right click the project name under Solution Explorer and go to Configuration Properties-General, modify the 'Platform Toolset' to Windows7.1SDK, since you already installed the Windows SDK 7. Please have a look at the following note:
##To change the target platform toolset, you must have the associated version of Visual Studio or the Windows Platform SDK installed. For example, to target the Itanium platform with the Windows7.1SDK platform toolset, you must have Microsoft Windows SDK for Windows 7 and .NET Framework 4 SP1 installed
If the above not works, you can also modify the platform toolset to Visual Studio 2010 (v100), which has the same compiler like Windows SDK 7, if you have the VS 2010 and VS 2017 on the same computer

C++ Universal Windows app only works when VS2015 project on install drive

Steps to rep:
Create a new, blank, UWP, VC++ app project (File --> New --> Project --> Visual C++ --> Windows --> Universal --> Blank App)
Store the project on D:\ (Visual Studio is installed on C:)
Hit F5 to build and run the app (I'm running in Debug, x64)
Error:
4. Now repeat the process but this time store the project on C:.
Everything works just fine.
How do I configure Visual Studio to let me run projects stored on a drive different than the drive on which VS is installed?
Specs:
Microsoft Visual Studio Enterprise 2015
Version 14.0.24720.00 Update 1
Microsoft .NET Framework
Version 4.6.01038
Windows 10 (fully patched).
As per my comment on the question, I have the same issue. I'm not sure this counts as an answer as it's a workaround, but this at least for a C# Universal project...
Go to the project properties for the app and set the Output path to a location on C drive.
e.g. C:\dev\MyTestApp\bin\x86\Debug
(for Debug build. Likewise substitute x64 for x86 for 64bit etc)
It will build and run with the output on C drive but the project remains on the other drive.
Not an ideal solution, but avoids the error.

C++ custom installer (launcher)

I have written a portable program in C# with certain dependencies (.NET Framework, Visual C++ redistributable, etc) that will run on Windows XP SP3 and up.
Because of that, the program needs a launcher that will run every time before the actual program does, checking that all the required dependencies are installed. If any of the dependencies are missing, an option to download and install that dependency, will be offered. If there are no missing dependencies, then the actual program is executed.
The launcher itself is relatively simple, consisting of some registry checkup and some WinAPI calls to verify the installed dependencies.
The file structure in the end will look something like this:
C#_compiled_portable_program.exe
C++_compiled_launcher.exe // executes on any system as low as a clean Windows XP SP3 install
The problem is that I have no idea how to compile a C++ code in Visual Studio 2013 that will run with absolute bare minimum dependencies (running on the runtime libraries that come with Windows XP SP3, at least).
Take for instance the absolute simplest C++ code:
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
printf("Hello world!");
return 0;
}
If I compile this with Visual Studio 2013 with the default configurations, it will not execute on a machine that doesn't have VC++ 2013 installed, showing some nasty errors.
I looked around for similar questions and the closest I could find was
Visual Studio 2010 MSVCR dependency removal?, but the answers are either incomplete or outdated.
So, just like an installer, is it possible to compile a C++ project in Visual Studio 2013 that will run pretty much on any system?
This is not perfect, but will do for now.
This is what I did to make a C++ project, compiled in Visual Studio 2013, execute ona system that doesn't have VC++ 2013 installed.
I created a new C++ project in Visual Studio 2013, File>New>Project>Visual C++>Win32 Console Application
Then in Solution Explorer right click the project and select Properties.
Click the Configuration drop down menu and select All Configurations.
In Configuration Properties>General, set Platform Toolset to Visual Studio 2013 - Windows XP (v120_xp).
With Dependency Walker determine what modules are imported by the compiled exe (the release build, not the debug one). The imported modules should be:
c:\windows\system32\KERNEL32.DLL
c:\windows\system32\MSVCR120.DLL
KERNEL32.DLL is a system file so we don't have to worry about that, and MSVCR120.DLL is the Visual C++ 2013 Runtime Library and we need to distribute this file along with the release build. When the executable needs to load a module, it first looks at its current location for that file and then in PATH (System32, etc). If we copy MSVCR120.DLL at same location the release executable is, then the program will run even on systems without VC++ 2013 installed.
Since the project is a 32-bit application, download VC++ 2013 Redistributable x86, install it on a 32-bit version of Windows (I installed it on a fresh Windows XP virtual machine), and copy c:\windows\system32\MSVCR120.DLL.
Update:
Never mind. You don't have to distribute a copy of VC++ Runtime DLL file, you can just configure the project to link statically to the runtime library.
Here is explained how to do it. You'll still have to change the Platform Toolset though, if you plan on executing on Windows XP.

Exe is not valid win32 application but running on 64bit

I have the application that I was modifying and then I compiled it in Visual Studio 2012 (C++ app). When I tried it on 64bit windows, application worked, but when I´m trying to run it under 32bit windows xp I´m getting message like ".exe is not a valid win32 application". I have found several advices on the internet but nothing worked so now I don´t know where is the problem because I´ve been testing it on several win7 64bit OS.
In Visual Studio in Configuration manager window I have selected option win32 at project´s platform column.
You should review all the project settings.
"Win32" is just a name. For e.g., you can target Machine->X64 in linker setting despite the configuration name.
Without more information, I would say you are linking against 64-bit only libraries which are not available on the 32-bit platform. Check your linker settings and build again.

Visual Studio 2012 Project targeting Windows XP using MFC

I have recently acquired source code from a VS2005 project that uses the MFC library. Firstly I upgraded the project to VS2012 and I can now successfully build and run the software on Windows 8. Next, I wanted to deploy the software on a Windows XP machine.
I have set the Platform Toolset to build to Windows XP (using the v110_xp option) and I have installed the 'Visual C++ Redistributable for Visual Studio 2012 Update 1' on the target machine. When I run the software, nothing appears to happen. Via some logging functions I can determine that a call to LoadFrame(IDR_MAINFRAME) causes an exception in kernel32.dll. I can't debug any further in to LoadFrame as remote debugging on Windows XP is not available in VS2012.
Any ideas what may be going wrong? Is the Visual C++ Redistributable package the correct version to be installing on the target machine? What should I be trying next?
UPDATE
My project is already set up to use the 7.1 SDK and has minimum required version set to 5.01 in linker options.
If I use InstallShield to generate an installer and include the MFC, CRT and ATL redistributables, the installer works and my program now runs on Windows XP. My understanding of the redistributables is that they simply copy the relevant dll's in to the system32 folder (or equivalent)? Is that correct?
However, if I simply copy the files over, run the vsredist_x86.exe or use Inno Setup to install the software & dll's, my program no longer works.
I believe you have read this blog. In summary, you need to use the 7.1 SDK, and you need to set minimum required version to 5.01 in linker options.
Using the working InstallShield project and the not-working Inno project I was able to determine that the real culprit here was an unregistered msxml4.dll. The error I was receiving gave no real clue to this outcome but I got there eventually...
regsvr32 msxml4.dll