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.
Related
This has probably been asked/answered dozens of times, but even after going/reading through many of these questions, i still can't figure out what to do...
Anyhow: I'm trying to write a standalone X86/32-bit C++ Windows console application using Visual Studio 2017 Community Edition (under Windows 10 x64) that runs some CMD.exe commands.
The problem: When trying to run the application on Windows 7, a dialog box pops up with a message saying that a required runtime library couldn't be found.
As i happen to be fairly new to developing/coding, you can probably understand how overwhelmed i am/was when going through Visual Studio's (project) options.
The goal to reach: I would like to know if there's a way (and how) to make my C++ console application work on Windows 7 and onwards, while ONLY using the operating system's built-in/default shipped libraries (if possible without requiring the .NET framework to run the program).
The application's purpose is really simple and is meant for learning the basics of Visual Studio development.
Hopefully someone can help me out. I know i'm supposed to uncheck any recent SDK's in the Visual Studio Installer, but at the same time it appears that the .NET framework seems to be a required component for writing/compiling CLI applications :S
I don't even know why you mention .net for C++. You only need the C++ runtime. That can be statically linked.
Well guys (i assume?), i've returned with some good news.
I'm also answering my own question since i have found a solution that gave me everything i asked/hoped for.
Code::Blocks IDE gave me both a very small program/exe of ~10kB, and it even worked without any additional/extra runtime libraries (i've tested this under a fresh/clean virtual OS # VMware Player).
Thank you all for the given support, you've been really helpful :-)
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 !
I have an existing application developed in VC++ 6.0 which has been installed in many customer sites throughout the world.
This application was working fine until sometime back when the Microsoft KB981793 hot fix was applied. This hotfix has changes related to Timezones and was crashing a crash due to an array overflow in our application code. When this patch was removed the application no longer crashed.
But the interesting thing is this crash was observed only in WinXP and Win2k3 machines and not in Vista or Win7 machines. Any reason why this works this way.
For XP and 2K3, Microsoft specifies minimum service pack levels as prerequisites. For Vista and 7 they don't require prerequisites even though service packs exist for Vista.
KB981793 for XP and 2003 touches Updspapi.dll, KB981793 for Vista or Windows 7 does not. This file is not related to timezones directly, but instead relates to the "setupAPI" (which includes device managament).
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.
As some of you may have noticed, a few hours ago Microsoft released Windows 7 RTM to those of us with a Technet or MSDN subscription.
I unfortunately didn't have the opportunity time-wise to test the new OS. I'm asking of anyone who used it with Visual Studio 2008 during RC what was your experience? Did you feel the RC offered a stable environment for it? Did it behave well under Windows 7? In short, can I rely on Windows 7 as my soon-to-be development platform?
On another note, did anyone did any tests the new crt? What were the results?
EDIT: As an afterthought, I'm interested indeed in both 32bit and 64bit experiences, since the OS will go to just one of these machines.
x58 chipset and i7 processing unit, Windows 7 RC x64, I had a lot of issues with programs locking up and crashing (not responding, invoking windows "Ill find out whats wrong! .. not) when you try to close the form. It kills development time.
Especially visual studio 2008, countless crashes and lock ups or delays. It does run good most of the time, but it has its moments.
My experience is that its not 100% solid.
I thought that it was weird, because its built in the Vista SP1 core, and my hardware runs Vista very solid, no hitches -ever-.
And yes, it was a fresh install of Win7, not an upgrade. I'm installing Server R2 though, so I'll see how that works out! :D
edit
I couldn't put my finger on it. Under Vista SP1/SP2 it runs rock solid. The video drivers worked great however for my GTX295, motherboard BIOS is up to date.
I don't think that the problem was driver related per-se, but I can't say. The symptoms purely came across as a software related issue with the OS and how it handles the Windows.
The Event logs are not a help, because a generic form crashing doesn't produce any real detail for me to burn through and say "Ah ha!".
I must say though, it was mostly Visual Studio and forms run under the debugging host process. Anything else was pretty okay, so it could be more or less just a compatibility issue
edit
After a fresh install of Windows Server R2 RC, after the initial installation and a driver install for a wireless adapter, the system fails to boot up properly (or atleast "detects" an problem), so you have to manually tell it to boot Windows up normally, which works.
After doing some Windows updates, same thing, but this time the OS fails even when trying to boot up normally and just does a reboot (probably a blue screen, but surpressed by my BIOS)
My experience with R2 was blazingly fast, both in performance and a drop in satisfaction and warm fuzzies about it working good
It seems that either way you go, on the newest of new hardware, it has its issues. Bummer.
The best way to write Win7 compatible programs is to use Win7 as a development platform. I use Win7 x64 with Visual Studio 2008 almost half a year and it looks pretty stable and has some helpful features (e.g. snap). At this moment all my programs are ready for certification and compliant with all Win7 requirements. I use VirtualBox to test my programs in Windows XP/Vista environment and VirtualBox works without any problems on Win7 too.
My hardware is Intel Q6600 processor on ASUS P5KC motherboard. ATI video card was unstable until some build of drivers, now it works fine. NVidia video card has no problems all the way.
I've been using Visual Studio 2008 under the RC for a while now. No issues at all. For that matter, I don't remember having any under the Beta either.
Windows 7 is good to go for development, as far as I'm concerned.
We've been piloting Windows 7 internally for some time now and have had very few if any troubles with it. I've personally been using it with Visual Studio 2008 (Full and Express) and have been very pleased with the OS overall. I recommend it. (It is fair to note, however, that we use beefy hardware, generally dual or quad core, 4GB RAM and good video cards for our pilot).
I been using windows 7 (x86) for few month now, never had a single problem with that.
Visual Studio 2008, Adobe products, Netbeans and everything else running just fine.
Win7 RC1, VS 2008 SP1 here. The only issue so far is graphical glitches in drawing VisualSVN icons in the Solution Explorer if I scroll the projects tree using mouse wheel.
Also sometimes Tortoise SVN cache crushes. But it might not be related to Windows 7.