how do i turn my VC++ 2008 program into something i can get to run on other computers. i have tryed using the .exe it makes in the debug but it will say that im missing some files and lists all of my .cpp file names and .h files(if i use it on other computers). i wanted something so i could encrypt my files because one of them is about encrypting passwords/other stuff so i can't have someone just open my files. also i would very much like someway to make them accept the terms and conditions so they can't sue me if they lose something, that would be very very nice. ^^
i only have Microsoft virtual c++ 2008 express edition that i got from their web site.
o also if i make something on windows 7 will it run in xp or vista?
You generally can't and almost never should distribute debug builds to client machines. At least three reasons.
Client machines will not have the debug versions of your dependant libraries, like the VC runtime (msvcrtd.dll), so they won't be able to run your app.
When compiling in debug, your code will in many ways run unoptimized. For one thing, you don't let an optimizing compiler optimize when you compile in debug, so it will run slower and/or fatter. For another, there are debug version of things like operator new which allocate much more than you ask for, which is used in runtime integrity checking etc. So your program runs fatter & slower once more.
When you compile in debug it is easier to reverse-engineer your code.
UPDATE:
And to answer your question if a Win7-compiled app will run on XP/Vista, the answer is 'yes' so long as you don't use any Win7 features.
You will need the redist pack for the binary to run on another machine (if it does not already have the pack installed).
You need to make a Deployment Project that generates an MSI, but I'm not sure your Express edition does that. As for encryption, compilation doesn't do that, and nothing stops people from disassembling your code. Finally, you probably should not be writing your own encryption algorithms, since most people get those wrong most of the time. Use something out of the box.
if you are compiling using .NET 3.5 in Win 7 it should work in xp and vista as well
(provided .NET 3.5 framework is installed on them).
The first part is already answered (release build, include redistributable C++ DLLs).
The second part, running on Vista/XP is not that trivial.
If you write a pure C++ program, it will run on XP and Vista, unconditionally. But once you include <windows.h>, you introduce a dependency on a minimum Windows version. The default today is still XP. That means that you cannot use any Vista or W7 feature directly, and therefore your program can run on XP.
But if you #define WINVER 0x0600 before including <windows.h>, then you can use Vista-specific functions. The price you pay for using those Vista functions is that your program won't start on XP anymore. Similarly, #define WINVER 0x0601 also gives you access to Windows 7 functions, on top of the XP and Vista functions. And again, using a Windows 7 function stops you from running on XP or Vista.
There are some tricks that allow you to use Windows 7 functions if available. Basically, they all boil down to calling GetProcAddress("some_windows7_function") and somehow handling the case where it returns NULL.
Related
I have a server. I want to add to it AES encryption.
I've tried using the Crypto++, after a lot of searching it compiled but it always throw exceptions that come from "CryptoPP::selfTestFailure".
I've read somewhere that it has something with this define in the file fips140.cpp:
// Define this to 1 to turn on FIPS 140-2 compliance features, including additional tests during
// startup, random number generation, and key generation. These tests may affect performance.
#ifndef CRYPTOPP_ENABLE_COMPLIANCE_WITH_FIPS_140_2
#define CRYPTOPP_ENABLE_COMPLIANCE_WITH_FIPS_140_2 0
endif
but when i change the define to 1 the project that i took the DLL from don't compile.
what did i do wrong? / is there any other way to implantation the AES algorithm?
... after a lot of searching it compiled but it always throw exceptions that come from "CryptoPP::selfTestFailure". I've read somewhere that it has something with this define in the file fips140.cpp:
The FIPS DLL is a special purpose Windows DLL with considerable restrictions. One of the restrictions is the Operational Environment or OE. The OE includes OS versions and service pack levels.
For the FIPS DLL, here are the approved OE's:
5.0.4 - Windows 2000 Professional Operating System, Service Pack 1
5.2.3 - Windows 2000 Professional Operating System, Service Pack 1
5.3.0 - Windows XP Professional with SP2 and Windows Server 2003 X64 with SP1
If the OS is wrong, or the Service Pack level is wrong, then that can cause the self test failure. One of the reasons it can cause a failure is because the DLL locates certain specific memory functions from the C++ runtime. If it does not find them, it throws an exception.
There's a not-so-readily apparent dependency, and that's the version of Visual Studio. The last version of the library that was validated is 5.3, and for it you need Visual Studio 2005.
Usually what you have to do now is set up a a build/test machine with the specific OS, ervice Pack level and Visual Studio, and then build and test on it. Then, when you install Crypto++ and your program in production, you use the compatibility tab to provide the runtime OE.
when i change the define to 1 the project that I took the DLL from don't compile. what did i do wrong?
If you want or need more specific answers, then you need to provide more information, like your version of Windows, your version of Visual Studio, and a call stack.
I would also encourage you to avoid the FIPS DLL if possible. Most users don't realize its special purpose and don't know how to use it properly. Its a pain in the butt to work with and its a constant source of problems.
If you want a DLL, then create a wrapper DLL that exports the symbols you want to export. Then, link to the static version of the Crypto++ library.
I have a rather large codebase that I've inherited and I'm kind of stuck in the past for the moment. I'm working in Visual C++ 6 in Windows 7 (32-bit), however, I'm targeting an XP machine (Service Pack 2). Corporate doesn't see the ROI of upgrading it to .NET and I've got about as much pull as a Mini Cooper towing a train.
With that said, I did seemingly successfully install VC++6 (without XP compatibility) on my Win7 machine and I can compile and run fine. However, when I try to deploy my release build to my XP machine, it crashes (while it does not crash on Win7). If, however, I build the same code on the XP machine directly, it'll work fine. Running VC++6 on my Win7 machine in XP compatibility mode crashes the IDE upon opening of my workspace.
The only thing I can possibly think of is that the code makes extensive use of ActiveX controls and the registry. I'm not sure if maybe there's some Win7 specific registry modifications that are being made or vice-versa. Then again, I know very little about the registry; I'm definitely much more comfortable working in a Unix environment when coding for pleasure, especially when I code in C/C++.
Here's a screenshot of the error I'm getting when it crashes. I'm imaging it's got something to do with ActiveX registration.
No, this isn't ActiveX related at all. This is you bog-standard, 1980's type assert. As you would have noticed, had you looked at winocc.cpp line 279.
I have developed some code under Unix using Cgwin, Linux and HP-UX. Since I don't want to start from scratch when doing some Windows stuff, I wanted to compile the code with Visual Studio 2008. Of course I'm aware that I have to do some adaptions, regarding system specific functionality like using fcntl. What I didn not expect though, was that there seem to be also problems using standard functions like snprintf etc.
snprintf and Visual Studio 2010 or
Error 4 error C3861: 'snprintf': identifier not found
Since there are also many other problems, I was considering using MingW. As far as I understood, MingW is a native Windows compiler right? So I still would have to port the systerm specific stuff, but I would like to know, if the move to MingW would give me any benefit by reducing the number of compatibillity issues.
I'm aware that this might be regarded as opnion based, but I don't want to compare MingW vs. MSVC, I just would like to know if the switch would reduce the porting issues, or if it is as waste of time and just as well stick to MSVC. I have ported code before, but always from Windows to Unix, which seems to have been much easier then the other way around.
As far as I understood, MingW is a native Windows compiler right?
If by native you meant Windows as a target OS, then yes. But if you were thinking about the building host - If you want so. MinGW is a GCC port, and can be built for Linux as well. Latest Ubuntu has both x32 and x64 versions of MinGW, for example.
I would like to know, if the move to MingW would give me any benefit
by reducing the number of compatibillity issues.
Definitely yes. Using GCC port means you will need to solve only OS-dependent issues, and skip compiler and Microsoft library differences.
I'm modifying a large C++ project whose first release was Windows 7-only to work on Vista and XP.
The main work will be to change the W7 API calls to use GetProcAddress at runtime (to avoid static linking with methods that are not available on the other platforms), and so I'm wondering if there are any tools that can help identify which calls need to be changed -- hopefully by examining the C++ code itself.
Failing that, would it be best to try building the project against an older Windows SDK? -- for example: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6510
#define WINVER 0x501
Now everything that is newer than Windows XP will cause a compilation error.
Replace everything that causes an error until none remain.
If you have some sed-fu, you can probably write a filter that directly finds all #if WINVER > 0x501 blocks in the windows headers, but for me, this is a bit out of my scope :-)
I would open your binaries using the depends.exe tool (either from your VS install or from here) under WinXP and Vista to see which functions can't be statically linked under these OSes. These would be the functions which your binary is using, but which are missing in older releases of the OS. You'll have to deal with them somehow: either implement them by yourself, replace them with something else or disable some of the functionality of your app.
I have been working on a VS 2005 project and have successfully generated an exe file which works fine on my system. However when I tried to run it on some other pc it didnt run. It throws up the error message "the system cannot run the specified program". Can someone tell me how to make my code immune to such message i.e. system independent?
platform used: Windows XP, VS 2005
the extension of all my code files is cpp but I know only c and thats what I wrote inside them.
I have seen before exe created on Windows Sp1 not working on SP2 and problems such as that.
This should help you perhaps.
I've seen this when you run on a different version of Windows that doesn't have some DLL you depend on. The easiest thing to do is statically link the C runtime (that's the usual culprit) and use depends.exe to see if there are any others.
You will almost certainly need to create an installer that installs your executable and any non-OS-included DLL's it relies upon. It is not always possible or desirable to statically link all dependencies. You can in many cases simply copy the DLL's to the same folder as the executable.
By default, even the C/C++ standard library is provided by a DLL. While the MSVCRT.DLL used by VC++ 6 is included with the OS since later editions Win95, the MSVCRT required by VS2005 is not included with XP installations (other versions I do not know). The run-time support is included VC redistributes package. You may need to arrange for your installer to include that installation, or you could be more selective is you know your dependencies.
Some Win32 API calls if you are using them are dependent on the OS version (check the documentation), but if you built and rin it on XP, it should normally work of any subsequent version of Windows. You need to define various API version macros if you want to extend support to earlier versions of Windows (which seems unlikley).
You might need to install the VS 2005 redistributables on the other machines, depending on how you have compiled your program.