Printable View
I am seriously planning to switch to the MS Visual Studio 2010 but I just realized today after updating my project for the whole day that while trying to run it on Windows 2000 it produces this error:
Is it true that the code compiled with it will work only on Windows XP, Vista and Windows 7?Quote:
<Executable file path> is not a valid win32 application.
Maybe you have build a 64 bit version of your application and Windows 2000 cannot run 64 bit executables. Build it as 32 bit and try again.
Could this be related (4. Target Name)? http://qualapps.blogspot.com/2009/10...as-with-c.html
:) No, it's not. Besides double-checking in the project properties I also ran the code on a 32-bit Windows XP platform and it ran just fine.Quote:
Originally Posted by Marc G
I especially like this part:Quote:
Originally Posted by S_M_A
I haven't either.... It took me about 3 hours to make one of my previous projects compile on VS 2010.Quote:
VS2010 introduces a new "Target Name" property in the General page of Configuration Properties. I still haven't figured out the rationale...
OK, so I made an experiment. I compiled a simple Hello World console application using MS VS 2010.
1. First, without MFC or ATL. Just the following line:
The size of the Release Unicode x86 build was around 6K. OK. I can live with that. But, if I run that code on Windows 2000 it simply shows the error "<Executable file path> is not a valid win32 application."Code:_tprintf(_T("Hello world!\n"));
2. Then if I do pretty much the same, Win32 console app with MFC and use the following lines:
The size of the Release Unicode x86 build (with statically linked MFC libraries) mushrooms to, get ready for this, 1.54MB!!! Just for those 3 lines of code and a sh*t ton of MFC stuff that will never be used in this project. And obviously it doesn't run on Win2K either.Code:CString s;
s.Format(_T("Hello world!\n"));
_tprintf(s);
All that is BAD!
:eek: Did you try that with dynamic linking to MFC? This pretty sure wouldn't run on Win2k either, but I would be interested in the release EXE file size.Quote:
Originally Posted by ahmd
In that case it becomes 6.50K, but it won't start without "MSVCR100.DLL" on my XP or Vista without VS 2010 installed. And I'm sure there're more dependencies to it so if you add all of them up it will total to 1.5MB or even worse. On Win2K though it still results in the same "not a valid win32 application" error.Quote:
Originally Posted by Eri523
On the side note, I link my code statically since otherwise you'll have to install DLLs anyway, which is a pain in the neck by itself. So why doing it?
OK, one more test. The same console app with MFC compiled on MS VS 2008 (without SP1) weighs only 208K and does run on Windows 2000. So go figure what MS is trying to sell us?
So, guys, don't rush to convert your projects. It may come with a caveat...
Ah, yes, that is about the file size I had expected in that case.Quote:
Originally Posted by ahmd
The name MSVCR100.DLL looks to me as if it refers to the basic (funny term in that context, isn't it? :D) VC++ runtime. The ones of them I have on my system for older VC++ versions range from 60 kB (how could they ever get it that small?) to 340 kB. The MFC runtime DLLs used to have names like MFC42.DLL and all have sizes slightly below 1 MB on my system. (Not counting the ones with similar names that obviously contain localisation stuff and are much smaller.)
The massive file size bloat you observed when linking your "Hello world!" statically to MFC is some kind of mystery to me. I really can't imagine that all the MFC functions in total have dependecies on one another. The only other reason I can think of is that they all reside in a single obj module what IMO would imply that they have all been in a single compilation unit. And that is definitely not the recommended way to go. ;)
Doesn't that pro edition have a tool that builds installation packages for you? I think earlier versions had. In that case it shouldn't be too much pain, at least not to the developer. But I have read in another thread these days that MS re-introduced a thing called "XCopy distribution strategy" (or something similar) together with VS 2010. This would mean, according to that thread, that all these DLLs get installed in the app directory instead of %windir%\system32. So linking dynamically wouldn't even save disk space. :sick: (Ok, you would save some space if your app is comprised of more than one EXE.) Maybe I'll dig that thread out at the end of this "CG pass" I'm in right now and post a question about that there.Quote:
On the side note, I link my code statically since otherwise you'll have to install DLLs anyway, which is a pain in the neck by itself. So why doing it?
EDIT: The correct term for what I was talking about appears to be XCopy deployment model. The thread containing the discussion about that topic is here and the relevant postings start at post #7. This post also has a link to MSDN that clarifies things a bit. In particular that MSDN article says that the XCopy deployment model is only one of three options when linking dynamically. (Of course it says a lot more, but that was the core point I got there.)
Oh, they try to sell us lots of stuff! In a recent magazine article I read a speculation that MS might discontinue VBA in the future, making us want to buy their full-blown developer tools for that purpose. (That speculation was based on the fact that VBA hasn't been extended while changing from Office 2007 to Office 2010.) And you can bet you couldn't use the VS Express Editions for that... ;)Quote:
So go figure what MS is trying to sell us?
I did some Googling and seemed to have corroborated my findings. I'm not sure what exactly is compiled into it but that's the fact. But the size of the file is not as bad for me as the code's incompatibility with Windows 2000. I'm not sure I will be able to explain for a client why my code doesn't run under that OS. And there are definitely people/organizations that still use Win2K. (And, yes, I know, Microsoft discontinued support for it.)Quote:
Originally Posted by Eri523
My further testing showed that the latest development environment that will produce a code compatible with Win2K (don't know about Win9x) is Visual Studio 2008 without SP1. So I might stick with that for a little while until Win2K is completely phased out.
What tool are you talking about?Quote:
Originally Posted by Eri523
I wouldn't be surprised by that. In my book Microsoft was always a company that put backward compatibility in front of everything (even in despite of it going in conflict with security). But that assumption was clearly shattered in the recent years. So, VBA, being a cause of many malicious attack is, I'm sure, not letting MS developers sleep soundly at night.Quote:
In a recent magazine article I read a speculation that MS might discontinue VBA in the future
I did some digging and it seems it's impossible to use the new compiler to build executables for Windows 2000 because the newest C/C++ runtime is using functions from the kernel that are simply not in Win2K.
I created a basic "Hello world" application with subsystem set to console, compiled it and tried on 2k and it wasn't working.
Then I tried to run dumpbin /headers on the executable and found:
When I compile with VC++ 2008 it says:Code:5.01 operating system version
0.00 image version
5.01 subsystem version
0 Win32 version
So, in VC++ 2010 I went to project properties > Linker > System. There subsystem is set to console and I changed "Minimum required version" to 5. Rebuild and tried to run on Windows 2k. Now the executable is recognized and it starts to run, but I immediately get the following error:Code:5.00 operating system version
0.00 image version
5.00 subsystem version
0 Win32 version
Meaning that the latest runtime is using functionality from the kernel that simply is not available on Win2K.Code:The procedure entry point HeapSetInformation could not be located in the dynamic link library KERNEL32.dll.
However, if you really need to support Win2K, you can use a new VC++2010 feature called "Multi targetting". With this feature you can use VS 2010 to compile the application with an older version of the compiler and libraries. I never tried it myself, but if you have VC++ 2010 and VC++ 2008 installed, you can use the 2010 IDE and use multi targetting to let 2010 use the compilers/libraries from 2008.
Thanks, Marc, I will give it a try. Suddenly it looks promising again :)Quote:
Originally Posted by Marc G
On the side note, am I asking too much with the Win2K compatability? Do you guys not support it with your software either?
In my book, not supporting Win2K at this point is analogous to a sales person saying that they won't accept two-dollar bills. They are rare, but are still in circulation.
I have no problem witn Win2K compatibility. As a matter of fact, the programs and DLL's my company creates can run on Windows NT, and last time I tried, Windows 98 with no changes.Quote:
Originally Posted by ahmd
Self-contained applications (ones where the EXE was built using static libraries), shlould always work, save for maybe API differences, regardless of the OS. I never have had to redistribute any Visual C++ DLL's.
Regards,
Paul McKenzie
I'm assuming that you're using Visual Studio to compile them, aren't you? If so, what version?Quote:
Originally Posted by Paul McKenzie
If you build any executable, and the dependencies are only USER, KERNEL, and GDI, then it doesn't matter what compiler you used. Those files exist, regardless of the system, on any Windows-based computer. In this case, the only difference are the API calls, where parameters to some functions may change definition, or may longer be supported for the OS.Quote:
Originally Posted by ahmd
I personally have not used Visual Studio 2010, only 2008. But to make EXE's "incompatible" requires a change in the executable file format, not just DLL version differences. I have seen no indications where Microsoft has changed the executable format, unless there is some special exe format that exists for OS'es above Windows 2000.
Regards,
Paul McKenzie
To make the point more clear, create an EXE file, and drag it into Dependency Walker. What are the DLL's that it depends on (the first level in the tree on the left)? If it's only KERNEL32, USER32, GDI32, then that EXE should work (or at least start to run) on any 32-bit OS (if it's a 32-bit app).
Regards,
Paul McKenzie
Paul, you must be using plain Win32 calls in your software without any of the MFC or ATL stuff or any extensions to the language at all. I normally opt to use MFC and some ATL and link them statically. So I ran my latest project though the Dependency Walker and it came up with almost a dozen of different DLLs. I know that most of that boils down to ntdll.dll, kernel.dll and user32.dll but still there are dependencies that are required to start an executable on the platform of interest and if only one of them is missing (or even an API call from an existing DLL) the program won't start.Quote:
Originally Posted by Paul McKenzie
My IDE of choice was MS VS 2002 for a long time (mainly because of the intellisense that was changed since VS 2003), but for the last couple weeks I'm trying to migrate to VS 2010. I was also always like you and considered loading some of the APIs in my software dynamically to allow compatability with older OS's.
I think I dedicated about several days to converting my projects to VS 2010, having liked some of the new features they introduced to the IDE, only to discover to my dismay that the code it makes is 1.5MB on average lager in size and doesn't run on Windows 2000 on top of it. (I'm not even venturing to try Win9x at this point.)
Well, I thought so too... until I saw it with my own eyes. I'm not pulling your leg. If you want I can attach a Hello World executable here and you can try it for yourself. I think Marc's explanation has some merit:Quote:
Originally Posted by Paul McKenzie
Quote:
Originally Posted by Marc G
Well, you're up for a surprise if you do :)Quote:
Originally Posted by Paul McKenzie
I'm also assuming that you don't have SP1 installed on your VS 2008, do you?
OK. I knew you'd ask it. So here you go. Two projects:Quote:
Originally Posted by Paul McKenzie
1. TestConsoleSize.exe
No MFC
Release Build (with MS VS 2010)
Use standard Windows Libraries
Size: 6.50 KB
2. TestConsoleSizeWithMFC.exeCode:_tprintf(_T("Hello World!\n"));
getchar();
Same thing but With MFC
Release Build (with MS VS 2010)
Use MFC in a Static Library
Size: 1.54 MB
Code:CString s;
s.Format(_T("Hello World!\n"));
_tprintf(s);
getchar();
I don't use MFC or ATL.Quote:
Originally Posted by ahmd
That may be, but that is not a change in the executable format. That is a change in the library being used and library calls, not the actual format of an executable file. Similar to one of us making calls that exist in Windows 7, but do not exist in Windows XP -- the executable is in a valid format, but will not run correctly when run on XP.Quote:
Well, I thought so too... until I saw it with my own eyes. I'm not pulling your leg. If you want I can attach a Hello World executable here and you can try it for yourself. I think Marc's explanation has some merit:
Yes, I am using SP1, and have had no issues with older (older than Windows 7) operating systems.Quote:
I'm also assuming that you don't have SP1 installed on your VS 2008, do you?
Regards,
Paul McKenzie
You didn't mention what version of the runtime library you're building with. Build them with the Multithreaded runtime (not DLL version), and then show us the results.Quote:
Originally Posted by ahmd
Regards,
Paul McKenzie
Well, I guess that if you don't use MFC or ATL then you might be safe.Quote:
Originally Posted by Paul McKenzie
I had access to MS VS 2008 at work and they let me compile a simple MFC project there and it ran under Win2K. But when they upgraded to SP1 MFC projects stopped working under Win2K or earlier. That has something to do with the new "fancy" MFC stuff they added there.
I can't seem to find that option for a console app. Where would it be?Quote:
Originally Posted by Paul McKenzie
The option is C/C++ -> Code Generation -> Runtime Library.
If you did that (changed to Mutlithreaded and not the DLL version of the runtime), you will see that your first example will not have any top-level dependencies on proprietary libraries (like MSVCRT80/90/whatever). That executable should run on any Windows 32-bit OS, probably even all the way down to Windows 98.
Regards,
Paul McKenzie
That also depends. If you statically linked MFC, then maybe it's still safe.Quote:
Originally Posted by ahmd
Regards,
Paul McKenzie
OK, just did. The Dependency Walker now shows only kernel32.dll but still when I run it on Win2K machine it gives me that "not a valid Win32 executable" error.Quote:
Originally Posted by Paul McKenzie
I need to get a trial version of VS 2008, install it and see if Marc's method with "Multi targeting" works...
On the side note, Paul, if you don't use MFC or ATL, how do you code your strings or dynamic arrays? With just plain C and Win32 it will be a torture. I hope you at least use STL.
I don't have a Win2K partition active right now, so I can't test myself at this moment.Quote:
Originally Posted by ahmd
I have Visual 2010 installed, but never used it up until this post. I created a non-MFC "Hello World" program, statically linked runtime, and it works in Windows 7 and Windows XP.
Everything is STL and/or standard library calls, with the obvious Windows OS calls when necessary.Quote:
On the side note, Paul, if you don't use MFC or ATL, how do you code your strings or dynamic arrays? With just plain C and Win32 it will be a torture. I hope you at least use STL.
Regards,
Paul McKenzie
Yes, it does. But that is not the issue. I can guarantee that it won't work on anything earlier than XP.Quote:
Originally Posted by Paul McKenzie
A non-MFC program that uses the statically linked runtime library with no dependencies on redistributables should work.Quote:
Originally Posted by ahmd
I looked at the same file in Dependency Walker on XP and WIndows 7. When you open the KERNEL32.DLL tree for Windows 7, you see all sorts of DLL's being used. Open the same file in DW on XP, and you get NTDLL.DLL as the only dependency on KERNEL32.DLL. The EXE works in both XP and Windows 7.
Even though I don't have Win2K available, I still don't see technically, given what I've described, how an executable built the way I stated would not work on Win2K. If you happened to have built your EXE using some new-fangled EXE format that only Windows 7 and XP understands, then it's a matter of setting the switches on the compiler to build EXE's that will run correctly on other 32-bit OS'es.
Regards,
Paul McKenzie
Paul, first of all, I appreciate your willingness to address this issue.Quote:
Originally Posted by Paul McKenzie
Since you don't have Win2K let's test it this way. Since you said you installed VS 2010 just for the sake of this post (which I appreciate, btw) build a release build for your test project (using VS2010) that you're sure will work under Windows 2000, attach it here and I'll try it on my side and tell you if it works or not.
If it doesn't work, then a lot of people would have complained who upgraded to VS 2010 for the enhancements in the C++ library, and they are developing standard C++ apps (no MFC, just Windows API calls, and STL/standard library usage, maybe boost, etc.).Quote:
Originally Posted by ahmd
There are a lot of companies who develop such things who don't touch MFC or ATL, but use Visual Studio because of its superiour development environment. Somehow, I doubt that these major players would like Microsoft, by default, generating EXE's and DLL's that will not work with Win2K, and for apparently no reasons whatsoever.
Anyway, here is the file.
Regards,
Paul McKenzie
Paul, I guess they should start changing their views about Microsoft ...Quote:
Originally Posted by Paul McKenzie
Many companies rely on having their standard, 32-bit software running on all 32-bit versions of Windows, save for Windows 95. The most these companies need to watch out for are API changes, and then change their code appropriately.Quote:
Originally Posted by ahmd
Upgrading the compiler is done solely for the C++ support for the new standard about to come out, better debugging and project management, etc.. They don't care one bit about MFC or ATL, but do care about the C++ support the compiler brings to them.
There should be some sort of compatibility switch within Visual Studio 2010 to allow creating EXE's that are valid executables for these other 32-bit OS'es. I remember that between versions of Visual Studio years ago, the import library format was changed, but Visual Studio still allowed creating import libraries using the old format.
Regards,
Paul McKenzie
Well, if you find it I sure would like to know it.Quote:
Originally Posted by Paul McKenzie
No Paul, there is no switch at all.Quote:
Originally Posted by Paul McKenzie
Windows 2000 support has been discontinued and VC++ 2010 cannot compile applications that will run on Win2K. It's that simple. If you need to support Win2K, use the VS2010 Multi Targetting feature to let VC++2010 use the VC++2008 compilers and libraries.
See also the following Connect issue which is an official answer from Microsoft.
Take a look at one of my earlier posts in this thread. The latest VC++2010 compiler is putting 5.01 as subsystem version in the PE headers. Windows 2K does not understand that. To keep it running on Win2K, the version in the PE headers should be 5.00.
Generally if you were using more than MFC and (pure) VC runtime, you are lost regarding W2k and W98 since at least VS2003 (VC7) you were dependent on .NET and newer dlls which simply were not available for W2K (let alone W98) and also were not available as static libraries (afaik).Quote:
Originally Posted by ahmd
If I would need W2k or W98 compatibility I would use VC6 and make the portability on source code level.
Regards, Alex
To address the static MFC size issue problem (not the Win2K problem) if you haven't already seen this, I thought I'd mention it. It will shrink your static MFC app back down to more reasonable size. See:Quote:
Originally Posted by ahmd
http://tedwvc.wordpress.com/2010/05/...visual-c-2010/
Yeah, thanks. But I made my decision already. VS2010 is not worth it (at this point in time). It's way overblown and doesn't add much vs. VS 2008 w/o SP1. So I decided to stick with the latter one and quite like it (no need to adjust every single MFC project I make). Maybe in a couple of years when Windows 2000 support and the size of code don't matter anymore, I'd go with a new version of VS. I think Microsoft made a big mistake by doing all this with the Visual Studio, they clearly needed a switch to leave out all that new stuff.Quote:
Originally Posted by Ted.
I dealt with the spin-off question earlier (EXE size). Now back to the original question - Visual C++ 2010 on Windows 2000 - here is my solution:
http://tedwvc.wordpress.com/2010/11/...-windows-2000/