Visual Studio 2010 and the Win32 API

Question

0.00/5 (No votes)

See more:

I've worked with Visual Studio V6.0 for thirteen years, and have a great deal of C++ code for it that I need to make available to projects developed under Visual Studio .NET 2010. However, even my simplest Win32 API-using test programs fail to compile or link. Is there some sort of retrofit or downloadable option required to enable me to use the Win32 APIs (and for that matter, the MFC V6.0 classes) with which I'm familiar?

I'd hate to think Microsoft had deliberately made VS 2010 non-upward-compatible from V6.0. I'd believe it...but I'd hate it!

All my best,
Fran Porretto

ALLOW ME TO EXPAND: The "great deal of C++ code" I mention above has all been extensively tested and used in multiple applications. For practical purposes, I can't do without it. Nor will I be permitted to make any but the most unavoidable mandatory changes to it. So alternatives that would require me to:
-- rewrite it;
-- make extensive changes to it;
-- use CLR / .NET alternatives;

...are ipso facto barred to me.

UPDATE II: I see from the responses of the past few hours that we've gotten into the "shoulds." This is a troubling development, especially among software engineers.

Smith: "That should work."
Jones: "I tried it just as you described it, and it didn't."
Smith: "But it should have!"

Please, please, please: Don't assume I'm stupid or inept. I'm a forty year veteran of the software wars. I strongly dislike admitting to failure, yet I'm here doing so because I need help with Visual Studio 2010. If you truly believe that it should do what I need done -- that is, compile and link C++ code that uses Win32 calls and MFC V6.0 classes and that was perfectly fine under Visual Studio V6.0, without the need for source code changes -- please lay out a procedure I can follow. And if I come back and tell you what Jones said above, take me at my word!

To be maximally specific: It's the calls to Win32 API functions, and the use of the special structures that some of them require as parameters, that are triggering compilation errors. I've gone looking for WINDOWS.H and WINBASE.H in the hope of debugging these problems, and they appear not to exist under VS.NET 2010. I'm also having difficulties with certain MFC classes whose definitions appear to have been changed, most notably CString. Are there VS.NET configuration, solution, or project options that would rectify these problems? If not, is there a download or an add-on that would rectify them, hopefully transparently to the code itself?

If you need to send example files or a really long answer, you can reach me at fwp@eternityroad.info. And thanks in advance, most sincerely. I'll be straining to repay any assistance you render me for a long time to come.

Posted 16-Aug-11 8:09am

Fran Porretto

Updated 17-Aug-11 2:34am

v3

Add a Solution

Comments

Maximilien 17-Aug-11 11:17am

Show us some sample code and errors ... we cannot help you further ... nothing too extensive, just a couple of lines.

If you can reproduce the errors with CString, then please show us the code, 2, 3 lines should be enough; it's quite a basic MFC class and should no be that broken between VC6 and VS2010.

What Win32 API are different and cause compilation errors ? if you do not tell us, we cannot help you further;

Did you look at the documentation ? what does MSDN say about those Win32 API ? did the signature changed ? did the link changed ?

Remember that between VC6 and VS2010 a lot of things happened, and as other wrote, the compiler was crap and non-standard.

Max.

7 solutions

Solution 1

You can still use the Windows API using pInvoke.

Go here [^]

You're going to find though, that requiring access to the Win API is infrequent from within .Net.

Posted 16-Aug-11 8:18am

#realJSOP

Updated 16-Aug-11 8:19am

v2

Solution 2

I would imagine there have been a some changes to the win32 API between VC6 and VS2010; and some re-write/update/error fixing will be needed to port code from that era.

Did you create a C++ project or a C++.net project ? those are 2 different project type.

What kind of errors do you get ?
Can you create a new project from scratch and move the code (files) to the new project ?

Posted 16-Aug-11 8:38am

Maximilien

Comments

Fran Porretto 16-Aug-11 14:48pm

The code I'm working with is of several kinds:
1. A large collection of library routines, which are intended to be linked into a static library (.LIB type) for use by larger applications;
2. Several very large applications of various kinds, most of which are Real-Time and MUST use low-overhead unmanaged system services, rather than the "managed" variety.
3. A group of non-Real-Time utility programs that support the use of the large applications mentioned above.

Right now, I'm trying to port the first group (the big collection of library functions and classes). I'd have no qualms about defining a new project / solution for it, but I'm just about forbidden to change the compilable code itself.

The services used in these programs are either Win32 API services (basic kernel services and I/O services) or the Microsoft Foundation Class wrappers for them. VS 2010 doesn't even provide references to them in its integrated Help. I suppose that's because Microsoft wants us all to use the CLR from now on, but it's making my life rather difficult.

All my best,
Fran

#realJSOP 16-Aug-11 16:01pm

Create a DLL that contains the library functions, and then write a .Net wrapper assembly for it. IMHO, you should not even be messing with .Net if you're not going to port EVERYTHING to it. The maintenance headaches alone won't be worth the time/trouble. Just port it all to the newest unmanaged C++ compiler, and call it a day. "Porting" usually just means a recompile. It went very smooth when I went from VC6 to VC8 back a few years ago. There were a bunch of warnings and a handful of errors, but when you consider it only took us a couple of days to convert 750,000 lines of code, that ain't bad.

Maximilien 16-Aug-11 15:35pm

well, if some API changes (deprecated or even removed) you will have to change the code.

We've ported MFC/Win32 applications from VC6 to VS2008 (and in the process of doing VS2010) with no real problem, but we could change the code whenever compilation errors and new compilation warnings appeared.

When you say your simplest test failed to compile and link, can you show us some of the errors ? or sample code that will generate the errors ?

Good luck.

Solution 3

If the code that can't be changed is in a DLL, you can still get to it from your managed apps, and indeed, you would write a manager wrapper assembly around the unmanaged DLL.

Posted 16-Aug-11 8:44am

#realJSOP

Comments

Fran Porretto 16-Aug-11 14:53pm

1. I'm talking about source code that I need to compile and link: some into static libraries, others into large applications. 2. It's entirely unmanaged -- Visual Studio V6.0 was BEFORE the whole managed-code idea was introduced. 3. My work is all Real-Time, and highly critical "hard" Real-Time at that. I would never be allowed to use the managed-code approach; the overheads are too great.

Solution 4

Why VS 2010? What prompted the need for that particular version, especially since it doesn't support your base code?

I ported all our VS6 code (couple hundred thousand lines) to VS 2008 with minimal disruption. MFC and WinAPI calls included.

Of course, I don't care about 64-bit applications so everything I build is 32-bit executables. On the other hand, that's a small price to pay instead of re-writing the whole thing.

Is VS 2008 not suitable for you?

Posted 16-Aug-11 9:07am

Chuck O'Toole

Comments

Fran Porretto 16-Aug-11 15:13pm

Chuck, if I had my way, I'd never leave VS V6.0. It's stable, I know it thoroughly, and it's served me very well. I have no need for any of the new features in VS.NET of any vintage, much less a particular need for VS 2010. I was commanded to move to VS 2010 by my management -- and you know the Manager's Motto: "Everything is easy, as long as I don't have to do it myself."

Chuck O'Toole 16-Aug-11 15:19pm

Damn, I knew that. I've run into this before, changing the tools you use just to be stylish. My management did that to me a couple of years ago. It seemed that upper management did a "tools survey", looking to come up with a "skill set" for all the minions. We showed up on the radar because we used VC6 for 6 or 7 years, didn't need .NET, etc. My argument that code / compilers / tools don't magically stop working just because of age, the bits don't wear out, didn't sway them one way or another. So it was off to VS 2008.

Fran Porretto 16-Aug-11 15:21pm

It's enough to make you crazy, isn't it? If I had any hair left before this disaster, I doubt I'd have it today!

Chuck O'Toole 16-Aug-11 15:34pm

Ah, we're a couple of old farts, I don't have any hair left. Management wasn't happy with me just moving to 2008, they also wanted .NET so I hit them where they understand. I gave an estimate of how much it would cost to re-write all the C++ code (for no engineering benefit whatsoever), convert to WPF for the GUI, and associated engineering resources tied up to do it. I also estimated how long it would take and that any other development on the tools would have to stand still until the conversion process was complete. Any new functionality would have to be on hold because we did not want to do double development, once in VC6 and once in VS2008. In the end, that at least convinced them to let me use C++ and MFC with VS2008 and that conversion was way easier.

Sergey Chepurin 16-Aug-11 16:55pm

I agree with Chuck, try VC++ 2008. I know the are many issues with upgrading straight from VC++ 6.0 to VC++ 2010. But it went fine for me in VC++ 2008. You can do it for free in VC++ 2008 Express.

Solution 6

Without having any details of exact failures it's hard to say what's wrong. However, the Win32 API is still there in VC10, and while some functions have been deprecated, and marked as such, things should still compile and link, albeit possibly with warnings.

I led the upgrading of a pile of projects from VC6 to VC10 earlier this year, and the three most common sources of problems were:

Implicit includes - where you previously could get away with not including all std lib header files you needed because they were included by some other file you included, VC10 has tightened that up a lot. So if you use anything from the C or C++ standard libs, check which header it's defined in, and include it.

Std lib changes - VC6 was released before the C++ standard (C++98) and in some cases the standard library distributed with it has best guesses rather than what ended up in the standard.

Project dependencies - the biggest problem by far for us. Previously (up to and including VC2008), project dependencies were stored in the solution file, but in VC10 they're stored in the project file. Thus, you can only have one set of dependencies, which causes problems if you use some projects in multiple solutions. My advice is to clean out that section of the project files and put all dependencies explicitly in the linker section. This is a known issue that Microsoft will not change.

Posted 17-Aug-11 0:08am

Orjan Westin

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Orjan Westin · Accepted Answer · 2011-08-17T05:03:00

Solution 7

Could it be that you have installed a .NET only configuration of Visual Studio, or that you're missing the SDK installation?

If you can't find WINDOWS.H there's something definitely missing. (I have mine in

C:\Program Files\Microsoft SDKs\Windows\v7.0A\include\Windows.h

) If you don't have them you'll have to check your installation media, or dig around at http://msdn.microsoft.com

Another thing: Visual Studio 10 has removed the global include/library folders, so this may also affect your compilation/linking. Instead, you have the environment variables (INCLUDE, LIB), project-specific include/lib directory specifications or a props file to include.

Posted 17-Aug-11 5:03am

Orjan Westin

Comments

Fran Porretto 17-Aug-11 11:06am

THANK YOU!! That's the sort of information I was hoping for. If I've received a .NET only distribution -- I didn't even know such a thing existed -- that would explain a great deal. I'll go to Microsoft and see what I can find there.

Thanks again!

Fran Porretto 17-Aug-11 11:29am

Orjan, you're a lifesaver. I was unaware that the appropriate SDK is OUTSIDE the Visual Studio 2010 tree of directories. With your help, I've found it and redirected the include and library paths for my test project to the appropriate places. It now compiles, links, and executes without errors.

The test project uses a handful of Win32 API calls that had been generating compilation errors. Now to see whether my MFC-using code will compile!

Fran Porretto 17-Aug-11 11:45am

And it does. I had two problems: One was not knowing about the V7.0a SDK; the other was not realizing that I had to change the project-specified character set to "NOT SET." Thanks endlessly!

Orjan Westin 17-Aug-11 12:14pm

Glad to hear you got it sorted, these problems can be endlessly frustrating. :-)

Richard MacCutchan · Accepted Answer · 2011-08-16T09:56:00

Solution 5

What does this have to do with .NET? C++ code from VC6 should be buildable in VS2010 with very few changes. If you are trying to build under CLR then I would venture to suggest you are doing it wrong.

Posted 16-Aug-11 9:56am

Richard MacCutchan

Comments

#realJSOP 16-Aug-11 16:03pm

5 - +1. Moving to VS2010 does not necessarily dictate moving to .Net. In fact, if it were me, I'd resist moving to .Net for the very reasons already stated.

Richard MacCutchan 16-Aug-11 16:06pm

Exactly my point, but much more succinctly articulated.

Philippe Mori 16-Aug-11 18:15pm

It should not be that hard to move to VS 2010 if you select the appropriate options (unmanaged code and maybe a few other options)...

It is hard to tell more precisely without knowing what kind of error you get and exactly what you using (STL? template?...).

You can always try an intermediate step like VS 2008 as it might be simpler.

Compile added files one by one if you have a lot of errors.

Richard MacCutchan 17-Aug-11 4:19am

I think you posted this comment in the wrong thread.