My application includes #include<regex>. Does this work on XP machines? - c++

I have an application which supports Windows version from XP.
Recently I have made changes to the application by including <regex>.
Does this application still work in Windows XP machine?
P.S.: I did configure my application to use MFC in a static library.
If this doesn't work what should I install on XP machine to make this work?

Related

Prevent start of program on an old Windows system

We have a minimum System requirement of Server 2012 and Windows 8.1.
We have programs written on C++.
Some programs in our Setup still don't use newer DLLs and start on a Windows 7 or Windows 2008 R2. Some use newer DLLs and don't start with a message that such a DLL isn't found.
Is there a way to prevent the start of a program on an old Windows System with a manifest or something similar? I would prefer that the user don't see a "DLL not found message".
The best way: Windows Loader tells the user that the executable doesn't match this OS.
I know that this works for Windows executables of the OS. Copying a newer EXE from Windows 10 to an old Windows version, even if new specific DLLs are not used.

Qt 5.4.0 deployment issue - missing vsprintf_s in msvcrt.dll

I'm stuck in a deployment issue with my Qt 5.4.0 application.
After two days of research, my app really doesn't want to execute on Windows XP !
I have created my deployment folder with windeployqt provided by my Qt installation. When I double-click on *.exe, I have always :
The procedure entry point vsprintf_s could not be located in the dynamic link library msvcrt.dll.
Dependency walker hasn't really helped me and I don't know what I can try now.
Note :
SDK : Qt 5.4.0 (MSVC 2010, 32 Bits)
IDE : QT Creator 3.3.0
Compiler : MinGW 4.9.1 32 Bits
Need to run on : Windows XP Pro SP2 32 Bits
App works like a charm on Windows 7 with same configuration (IDE, compiler, etc.)
While Guilhem G. is correct in the broader sense, it doesn't mean you actually called that function yourself (speaking now to a theoretically other person running into this issue like me, heh). I believe it's a bug with MinGW's XP support; I've seen bug reports of similar issues, including nearly the exact same issue in a much earlier version of Qt that was then fixed. I haven't seen this particular incarnation, which I actually ran into myself. I suppose I should probably submit a bug report!
Anyways, I've fixed it without changing any of the code I've written myself. What I had to do to fix it was twofold:
Switch over to using the msvc2010 compiler, since that set of C++ libraries rather unsurprisingly runs fine on Windows XP (AFAIK they still haven't dropped XP support with the latest version).
Switch over to Qt 5.5 (I'll explain why at the end).
For the compiler, you'll need then either Microsoft Visual Studio 2010 (hence the name), or the older Windows SDK that ships with it; the "Microsoft Windows Software Development Kit for Windows Server 2008 and .NET Framework 3.5" release should do the trick for you if you don't have a Visual Studio 2010 license.
Once one of those is installed, I'd encourage you to install Qt 5.5 as compiled by MSVC2010. You can either start a fresh installer or use the Qt Maintenance Tool which should already be installed.
Once that kit is installed, within your project (selecting "Projects" from the left-side menu) you should be able to go "Add Kit" and select Qt 5.5 msvc2010 32-bit, and if you now recompile and redeploy your application, it should run fine on XP.
Now, why did I insist on you upgrading to Qt 5.5? Well, there's some underlying issues with choosing a working OpenGL renderer on each version of Windows, and Qt 5.5 simplifies that a lot by having it fall back on OpenGL or ANGLE depending on what capabilities are actually detected, plus IIRC some other related fixes. So certainly if you're deploying a QML / Qt Quick 2.0 app across multiple Windows versions like I'm doing, it's worth upgrading to Qt 5.5.
The error was I called "sprintf_s" somewhere in my code (ok for recent windows on my dev machine but not for XP).
If you have the same problem when you search in your code don't use exactly the name of the function in the error message but an expression like *_s.
You probably call a secure API function somewhere !

How to make Ws2_32.lib work with VS 2013 Project targeted at Windows 8.1

So I have a Visual Studio 2013 Update 4 solution with 2 projects inside, one target Windows 8.1, other Windows Phone 8.1 configured to build static lib.
Project is open sourced, so here is the solution for reference:
https://github.com/gideros/gideros/tree/master/winrt
What I need to do, is to make it use networking code, which uses winsockets. Since this is a library project, there was no Linker section in project properties, so I simply included
#include <WinSock2.h>
#pragma comment(lib, "Ws2_32.lib")
Both projects built without errors and when library included in Windows Phone app, it worked exactly as expected, but in Windows app networking part was not working, but also no errors or crashes.
I ran it through App Certification program and it said:
Error Found: The supported APIs test detected the following errors:
API WSACleanup in ws2_32.dll is not supported for this application type.
and lots of other references to ws2_32 library
I started searching on internet, and there were lots of posts stating that you can't use winsocket on Windows 8.1, you have to use Microsoft's winrt socket implementation etc.
But then I stumbled on this blog announcing that it is now (since VS 2013 Update 3) possible to use winsock on both Windows 8.1 and Windows Phone 8.1
http://blogs.windows.com/buildingapps/2014/10/13/winsock-and-more-open-source-for-your-windows-store-apps/
Quoting:
We’re happy to announce that starting with the release of Visual
Studio 2013 Update 3 (download) in August, the Windows App
Certification Kit (WACK) allows use of WinSock APIs in your Windows
Store apps. And since WinSock was already allowed to pass
certification on Windows Phone, this work completes the story. Now
WinSock is available universally across Windows 8.1, Windows Phone
8.1, and universal apps.
As I had VS 2013 Update 4, it should have already worked. So I checked App certification version (it was 3.3), and it stated it had update available, so I downloaded Windows SDK for Windows 8.1 from:
https://dev.windows.com/en-us/develop/app-certification-kit
And now I can't even build the project, because it says that all Ws2_32.lib parts are missing for Windows 8.1 target. (while Windows Phone 8.1 still builds and works as expected)
So is it even possible to use winsockets on Windows 8.1 apps?
And if yes, what am I missing?
Update 1:
It seems to be possible, but the problem is with my set up.
When I check the header files where my project points, then they are:
for Windows phone its
Program Files (x86)/Windows Phone Kits/8.1/Include/winsock2.h
for Windows it
Program Files (x86)/Windows Kits/8.1/Include/um/WinSock2.h
And when I check the file that is for Windows, then it has a preprocessor defined:
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
And it does not go into this if statement, thus for compiler this file is basically empty
I even tried to uninstall Windows 8.1 SDK, which did not change anything.
Then I manually removed files from Program Files folder and installed a new one from
https://dev.windows.com/en-us/develop/app-certification-kit
still I have the same header. So where do I get latest Windows 8.1 SDK with proper winsock2 header file?
Update 2:
So I removed everything and re-installed clean VS 2013 Express Update 4 and again same result, it all builds without errors, but networking does not work on Windows 8.1 app, while it perfectly works on Windows Phone 8.1.
It is like Windows 8.1 have only empty stubs, that do nothing.
I've been asking in Windows developer forum and one of the Microsoft representatives stated that, quoting:
If you have VS 2013 Update 4 properly installed, then you will have
gotten an updated Windows 8.1 SDK. In that version of winsock2.h, only
the ASCII versions of most of the WinSock APIs are excluded from
Windows Store. You have to use UNICODE exclusively for Windows 8 Store
apps.
Unfortunately I have no idea what that means and how should I proceed. If that means defining UNICODE macro then it is already defined.
Update 3:
I've managed to debug the winsocket code and everything is running as expected there, server is listening on the port. But nothing can connect to it. It's like it is running in sandboxed mode
Update 4:
Running netstat and wireshark all seems to work correctly and see server and I can even connect to it from other computer. But I can't connect from the same computer.
And it seems that MS forbids Windows apps to communicate with desktop apps on the same machine
I have no idea why, anyone can provide any insights?
How can a Metro app in Windows 8 communicate with a backend desktop app on the same machine?
The last question is
If VS 2013 Update 4 bundles winsock2 header that builds with WACK 3.3 that does not allow winsockets, while Windows 8.1 SDK update has WACK3.4 that allows socket API, but bundles older winsock2 header which does not build.
How to get WACK3.4 with correct winsock2 setup?
WinSock is supported on Windows and Windows Phone, and is allowed using WACK 3.4. It works for me using both #pragma comment(lib, "ws2_32.lib") and by adding ws2_32.lib directly to the project settings.
It looks like there is something wrong with the way you are building the project after the upgrade; can you post the errors you got after the upgrade?
So basically sockets do work, but there are couple of cases to be aware of.
There is a network isolation, which does not allow to connect to Windows Store apps from same machine (as I did in my tests and thought networking does not work).
But if you can connect from remote machine, everything works as expected.
More info on that:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd374089%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
But you still won't be able to pass WACK (which is not needed to submit to store, but still)
Problem is that VS 2013 Update 4 bundles winsock2 header that builds and works and it has WACK 3.3 software that does not allow winsockets.
While Windows 8.1 SDK update has WACK3.4 that allows socket API, but bundles older winsock2 header which does not build and work.
As you don't need to run WACK to submit app, mostly it won't be a problem, but as I needed to check if there are any other specific libraries I use, that can be prohibited, then I had to only install single (App certification) component from Windows 8.1 SDK from here:
https://dev.windows.com/en-us/develop/downloads
And I have WACK 3.4 and proper winsockets now
Still too bad about network isolation, that basically kills the purpose of what I was porting in the first place. Making all the work basically in vain.

Which OS to use to build For XP and Win7

I have a software which has to be deployed in Windows Xp and Windows 7 32 bit versions. Is it Ok to build the software in Win XP for for both platforms?
or
Should I build in Xp for deploying in Xp and build in Win7 for deploying in Win7?
The software is developed in C++
Both operating system will do the job. Just use the proper SDK version and deployment target constants (see targetver.h in C++ project template).
Yes you can build on any (modern) windows version for deployment on any other.
But you probably want to test on both!
If you really have to choose, use XP since Win7 is most likely XP-compatible.
I mean, there are more chances that your program will not run under XP if developped with Win7 than the opposite.
Of course, if you use the correct libs, it should be OK, but what if by mistake you use a Win7 only feature ?
More recent version are expected to be compatible with old versions, not the opposite.

Building a Volume Shadow Service app for release

How should an application that uses the Volume Shadow Copy service be built for release? I've been building and testing in Windows 7 and everything looks good so I built the app to test in Windows XP and I get an error on startup:
The procedure entry point VssFreeSnapshotPropertiesInternal could not be located in the dynamic link library VSSAPI.DLL
Now, I realise that a way round this is to use LoadLibrary and call the function if it exists but surely the function should exist in the first place to be able to use VSS?
I read somewhere that I would need to build a different version for XP, Server 2003, Windows 7 etc but I've not seen that in other applications that use VSS.
What is the correct way to build a VSS app?
Thanks,
J
Take a look at HoboCopy source code.
This should answer every question you could have.
It's free (for personal use) and C++ src code covers all Windows versions from XP to 2008.
Src has moved, anyway start from here.
Note: The Windows SDK can be used to develop VSS applications only for Windows Vista and later Windows operating system versions. It cannot be used to develop VSS requester's, providers, or writers for Windows Server 2003 R2, Windows Server 2003, or Windows XP.
link: VSS Application Compatibility (Windows)