If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

VS2010 introduces a new "Target Name" property in the General page of Configuration Properties. I still haven't figured out the rationale...

I haven't either.... It took me about 3 hours to make one of my previous projects compile on VS 2010.

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:

Code:

_tprintf(_T("Hello world!\n"));

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."

2. Then if I do pretty much the same, Win32 console app with MFC and use the following lines:

Code:

CString s;
s.Format(_T("Hello world!\n"));
_tprintf(s);

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.

Re: MS Visual Studio 2010 and support for Windows 9x and 2000

Originally Posted by ahmd

2. Then if I do pretty much the same, Win32 console app with MFC and use the following lines:

Code:

CString s;
s.Format(_T("Hello world!\n"));
_tprintf(s);

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.

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.

Re: MS Visual Studio 2010 and support for Windows 9x and 2000

Originally Posted by Eri523

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.

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.

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...

Re: MS Visual Studio 2010 and support for Windows 9x and 2000

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.

Ah, yes, that is about the file size I had expected in that case.

The name MSVCR100.DLL looks to me as if it refers to the basic (funny term in that context, isn't it? ) 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.

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?

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. (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.

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.)

So go figure what MS is trying to sell us?

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...

Re: MS Visual Studio 2010 and support for Windows 9x and 2000

Originally Posted by Eri523

The massive file size bloat you observed when linking your "Hello world!" statically to MFC is some kind of mystery to me.

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.)

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.

Originally Posted by Eri523

Doesn't that pro edition have a tool that builds installation packages for you?

What tool are you talking about?

In a recent magazine article I read a speculation that MS might discontinue VBA in the future

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.

Re: MS Visual Studio 2010 and support for Windows 9x and 2000

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:

Code:

5.01 operating system version
0.00 image version
5.01 subsystem version
0 Win32 version

When I compile with VC++ 2008 it says:

Code:

5.00 operating system version
0.00 image version
5.00 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:

The procedure entry point HeapSetInformation could not be located in the dynamic link library KERNEL32.dll.

Meaning that the latest runtime is using functionality from the kernel that simply is not available on Win2K.

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.

Re: MS Visual Studio 2010 and support for Windows 9x and 2000

Originally Posted by Marc G

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

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.

Re: MS Visual Studio 2010 and support for Windows 9x and 2000

On the side note, am I asking too much with the Win2K compatability? Do you guys not support it with your software either?

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.

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.

Re: MS Visual Studio 2010 and support for Windows 9x and 2000

Originally Posted by Paul McKenzie

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.
...
Self-contained applications (ones where the EXE was built using static libraries), shlould always work

I'm assuming that you're using Visual Studio to compile them, aren't you? If so, what version?

Re: MS Visual Studio 2010 and support for Windows 9x and 2000

Originally Posted by ahmd

I'm assuming that you're using Visual Studio to compile them, aren't you? If so, what version?

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.

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.

Re: MS Visual Studio 2010 and support for Windows 9x and 2000

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).

Re: MS Visual Studio 2010 and support for Windows 9x and 2000

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...

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.

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.)

Originally Posted by Paul McKenzie

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 exectuable format...

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:

Originally Posted by Marc G

the newest C/C++ runtime is using functions from the kernel that are simply not in Win2K

Originally Posted by Paul McKenzie

I personally have not used Visual Studio 2010, only 2008

Well, you're up for a surprise if you do

I'm also assuming that you don't have SP1 installed on your VS 2008, do you?