• Microsoft's Visual C++ site
• Microsoft's Visual C++ 6.0 "sneak preview" site Documentation and white papers on the upcoming product
• TechNetCast Visual C++ 6.0 forum

[Commercial break}

MB/WS: Thank you.

MB/WS: Thank you.

MB/WS: I think there's a lot of interesting things with VC6. You mentioned most of them, I think. The statement completion work that we did, for example, which is a lot like Visual Basic, and we've added a few tricks that are unique to VC in it.

MB/WS: Well, it's just a little bit more advanced than that. It reads C++ syntax as you're typing. So if you have an instance of some variable, say you have a CString [variable] and you type [the variable name], as soon as you type the dot, we'll drop down a list of the member variables. And once you pick a member variable, you'll get parameter help for it. […] It's also context sensitive for dots and arrows and things like that.

MB/WS: Any C++ class that you have included in your project.

MB/WS: Or struct.

MB/WS: It's a little bit different database. But, yes, essentially. Anything you can see in (unintelligible) you can get statement completion on. And we also have statement completion on all of MFC and all of ATL and all of the WIN 32 API.

MB/WS: It is. On the tools options menu.

MB/WS: Probably the other major one is the edit and continue feature in the debugger.

MB/WS: You are debugging your application and you discover a problem with the code that you're stepping through, or maybe you're not stepping through it but just running. You can modify that code in the debugger and build, we will then patch the EXE image in memory and continue executing that application. It's an extremely fast way to fix bugs while you're in debugger.

MB/WS: The image is laid out in memory with a little bit of extra space in between each function.

MB/WS: No, because we can take that space and jump out of there… It is less efficient run time -but who notices, [this is] just for debugging.

MB/WS: Absolutely.

MB/WS: As you exit the debugger, all the OBJs that we built to patch the in-memory image are still on disk. So when you exit the debugger, we will relink the actual EXE.

Caller, are you on the air?

"SCOTT": Yes.

"SCOTT": It's Scott.

"SCOTT": Yes. I was wondering if there's any companies out there that extend MFC at all.

MB/WS: Well, Scott, Dundas Software is one of our favorites... You should probably check to see that the caller is actually Scott Wingo…

Actually, we had Scott on the program. We had him on the program a few months ago and we saw him at SD.

"SCOTT": I just wanted to say Visual C++ 6.0 is excellent. Good job, guys.

MB/WS: Thanks, Scott. And Stingray is one of our favorites, as well…

MB/WS: Yes. To do this statement completion work, we came up with kind of a simplified C++ (unintelligible) that runs all the time in the background so that we could always keep up to date with what you are typing in and the classes you were declaring.

And we found that we could actually use that also to update class view and create a very dynamic class view pane that -- in previous versions of VC we had, but you either had to save the project or build the project before you got everything updated.

MB/WS: Certainly. But we spent a lot of time optimizing it and making sure that it was interfered very little with the work you were doing in the IDE. So we think definitely on any typical machine that we've tested on you see no performance degradation at all. And if you do, you can turn it off.

MB/WS: As Mike mentioned, the way Edit and Continue is done is by adding padding so that functions and data can grow. But once you exceed that padding, then we can't grow it any further and you would have to just stop the debugger and rebuild, like you would have had to in VC5 or VC4.

But we found that a lot of people can spend a very significant amount of their time actually just writing code in the debugger. In fact, the guy who wrote it continues spending a lot of time doing that, so it's pretty robust.

MB/WS: Yes. The idea is that any time you're broken, any time you're stopped, you can use the debugger and pop up a modules list. And that will enumerate the EXE that you have loaded, obviously, as well as all the DLL's that are attached to it.

And it's a pretty cool dialog because it shows you the load order for all those DLL's, it shows you the exact path that they came from, it shows you the library name, which could be different than the module name. And it's very, very handy for situations where you have many, many models in your app.

MB/WS: If they're loaded, yes, absolutely.

If the load has been deferred, you won't see it in the list. If the DLL has been initialized and attached to your process, you will see it.

MB/WS: Right.

MB/WS: Exactly. The linker and the process loader have done a little work together to conspire and find a way to defer the loading of DLL, exactly like you mentioned. [When a DLL entry point is referenced] for the first time, the loader realizes, well, now it's time to bring this DLL into memory. It brings it into memory.

If the entry point can't be found in the DLL an exception is thrown. You can set up an exception handler for that and figure out what wasn't found and what library and pop up a message box that actually has English text in it that explains what's missing, instead of like some ordinal was not found in the system DLL or whatever the terrible messages you normally get are.

If you don't like exceptions, you can also set a hook for that exception handling. And the hook is sometimes more convenient, anyway, because it lets you set up (unintelligible) in a global scope.

MB/WS: No, the game's over right there. Because we're expecting that you're going to enter the DLL, you're going to switch across the boundary and (unintelligible) to get out.

MB/WS: Unfortunately, not in this release, no.

MB/WS: The process has something called the import address table that is a list of all the functions that you're importing from DLL. Once the EXE is loaded and all the DLL's get loaded, the loader then goes through that address table and fixes up the addresses so that when you call into a function you jump to the right address on the DLL.

MB/WS: One of those. The operating system, yes.

MB/WS: We have some kind of pseudo import address table in the EXE header that we populate with all of the imports you're importing from a DLL. And once you are going to call into that DLL, the code that was generated directs that call into the pseudo import address table, at which point then we can load the DLL and fix the address up to the real address in the DLL.

MB/WS: In a way.

MB/WS: There are two drawbacks. One is, like with any technology, there's some sharp edges. We don't want to see people running out and saying, "Well, gee, let me delay load Kernel32" because you need Kernel32 to run [the application…]

So if you start switching on delay loading for libraries that are necessary to help you initialize or necessary to help you run, you're actually wasting time instead of saving time. Because you're going to [attempt] to defer the load, but the load's going to happen right away, anyway. And there's no net gain, and probably a net loss if you start doing that.

The other down side is that you need to be careful with the error handling. So you should have an error handler hooked up unless you're absolutely positive you're going to find all the DLL's.

[Commercial break]

MB/WS: Thanks. Hey, we heard that spot in the break there... We're wondering if Rosie Perez is going to be on the show with us later.

MB/WS: That would be great. Because she doesn't respond to my letters.

MB/WS: Yup.

MB/WS: It's just a more compact library format.

MB/WS: No, they are compatible.

MB/WS: We degrade the file format as we load, as we open the library.

TNC: So new applications will be able to read the old file format.

MB/WS: You got it.

MB/WS: Absolutely.

MB/WS: Holy cow... So we took everything that we did in the technology preview and polished it up and made sure it worked and now it's really part of the product. So that, to recap, includes like all the new common controls, all the IE 4.0 compatibility stuff. During the intro you mentioned CHtmlView, which hosts the [web browser control].

MB/WS: Absolutely.

MB/WS: Right.

MB/WS: Right. So certainly the technology preview went out as near Beta quality, but we've done a lot of work in the meantime to fix up bugs and continue tracking the platform API to make sure MCF is fully compatible with it.

MB/WS: The Internet client SDK is the SEK we release when we ship a new version of IE and its technologies. And so it would allow VC++ developers or any C developer to immediately start taking advantage of those new API and technology.

MB/WS: The idea is that then in the next platform SEK release they pick up all the new stuff that might have been released in the interim Internet SEK release.

MB/WS: Yes. And it comes with the distribution CD.

MB/WS: Absolutely. So we've polished off a few things in MFC and ATL to make sure that applications that use, either components using MFC or applications using ATL would be a little easier to write. We've had tons and tons of supporting calls and feedback about I get this mysterious linker error, or this symbol is not found, and it's very confusing for users.

So by eliminating some of the technical barriers we just made that whole process a lot smoother.

The work is sort of hard to describe. I mean, it touches a lot of classes here and there throughout both frameworks, but we've just enhanced the compatibility, is the whole upshot.

MB/WS: Yes. So the object wizard now features a check box that says -- actually, it's a (unintelligible) project wizard that has a check box that says include MFC support. Yes, so that helps a lot, as well.

MFC also adds support for active document containment. We've had active document servers in MFC probably since 4.2, right?

MB/WS: Yes.

MB/WS: We also did a lot of tuning for the libraries linking patterns. So customers will notice that statically linking to MFC will draw in a lot less spurious garbage into their statically linked apps.

Realistically, you'll see probably between a five and ten percent decrease in the size of an apparently that's linked that way. So if I link Wordpad out of the sample statically to MFC, it's about seven percent smaller than it used to be. For small utilitarian apps, or situations where ATL customers are using classes from MFC like C string and C (unintelligible) and those guys, the savings is a lot more substantial, on the order of 30 to 50 percent.

MB/WS: Mainly to take advantage of these improvements that we've done. Certainly the improvements affect the initialization pattern in the DLL and what pages get hit as the DLL comes into memory. But we think that for most applications that we hear about customers using in MFC, it turns out that static linking is just a little bit better story for them.

You know, we certainly won't quit supporting the DLL, but on the other hand we want to make sure that users don't think that dynamically linking MFC is the only possible way to use the library.

MB/WS: At the expense of some executable size, sure. Yes, that's true.

MB/WS: So one of the other things that we did, and this is also part of the integration work we did, is we have now support for Universal Data Access in MFC, as well as ATL, and it's actually using the same implementation. It's a shared implementation of those template classes that wrap the OLE DB interfaces.

MB/WS: That's right. The provider is like the driver.

MB/WS: Right. And so Microsoft's [data access strategy] centers around ADO and OLE DB.

We want to help people make a decision between all the different database API's they could use and try and recommend the ones that we think they'll get the most benefit from.

MB/WS: We have the shared DLL that lives in the Windows system directory. MFC versions 4.2 and 5.0 use the same DLL name. All that really means is that we've taken steps to insure as best we can that any application that was built with VC4.2 or VC5.0 and is already installed on the system will continue to work without problems after you install VC6.

MB/WS: Right. So the entry points are all the same, exposed to the same ordinals. For situations where we've added new functionality, we've been, you know, it's all through an automated process. But we've been very careful to make sure that the new entry points start at previously unused ordinals. Therefore, the DLL ends up being compatible. We're careful not to change underlying functionality, we're careful not to change the size or shape of any of the objects.

MB/WS: That's the simple solution, but it's fraught with problems. You can imagine that, you know, taking up a megabyte at a time for each release in someone's systems folder is a little bit annoying. But on top of that, there is a lot of scenarios where MFC is integrated in versions, incompatible versions.

So say you write an application, you rebuild it for Visual C++ 6.0. And you would load that hypothetical MFC 60.DLL. Then that application turns around and creates a control. And that control is purchased from a vendor who hasn't updated the control yet. And the control is relying on MFC 42.DLL.

That means that you have two versions of MFC in memory and your application starts to become a little big piggish. Because you have so much of the same code redundantly in memory.

Comparing two versions that way seems like a pretty insignificant problem. I mean, you're doubling the working set, so maybe, you know, twice, one megabyte, twice 1.2 megabytes just for MFC. But what if we did that for every release? If we did that for every release, you can imagine that you'd have four or five releases of MFC in scope of that problem. So you're multiplying the working set by five or six times.

MB/WS: We'll continue to support all the platform API's that our customers are interested in us supporting. And we think it's an important role that we have for Microsoft.

We do have plans in future versions to componentize and help granulize that library so that you really are only using the pieces of it that you need.

MB/WS: That's the brunt of our philosophy, I guess, in the next few versions of MFC, is to make sure that it is more granular and that you only pay as you go as you use parts of the library.

On the other and, I have absolutely no intention of sacrificing any support for any API or any pre-built functionality that any user works. Since -- those two strategies enable each other. If I make some implementation that's very popular but extremely expensive, it really doesn't matter as long as you only pay that expense in size if you're using that feature. People who don't use that feature will be quite happy to have it in the library when they need it, as long as they're not carrying it around with them everywhere they go.

MB/WS: Well, it turns out that it's smoke and mirrors…

We found out that the WIN32 API implementation stores the last error for a process, actually for a thread, in a particular location in memory, and we can go spy on it any time we want to.

MB/WS: I don't know. It's some number between one and four billion, but I don't know it off the top of my head…

MB/WS: Probably lots of neat stuff. You'd probably have to go get an Andrew Schulman book, though, to find out exactly what's going on there.

MB/WS: When you enter a watch variable in the watch window, you can qualify that variable with various formatting options, just by typing the variable name, comma, and then the one or two character designation for the formatting option.

And so, simply, if you have a variable that is containing an H result, you can type in the variable name with a comma, HR after it and we'll display the actual value.

[Commercial break]

MB/WS: Sure does. You know, we've done a whole lot of work do enhance what you can do with the wizard.

So you'll notice that the MFC wizard allows you now to produce a non-doc view application right out of the wizard. We've also enhanced the console stuff. And we've done a bunch of stuff for the ATL object wizard as well. There's lots of whole new object types that you can add from that wizard down.

MB/WS: Well, maybe not so dangerous, but I'm sure it was exciting.

But, yes, you can do that right out of the wizard right now. There are a few situations where doc view is just not appropriate, and we wanted to support those applications as well.

MB/WS: Sure. The plain WIN 32 console application's been there probably since 4.0. I know it was in 5.0. But we've also added MFC support to that guy. So if you are using MFC from a console app, you can flip a button and there it is.

MB/WS: The compiler guys, as well as doing some optimization for floating point and for in-line functions in this release to improve run time, have also gone on a binge to try to help people find bugs in their applications before the applications actually run. So the idea behind the new warnings is just to be a little bit more conservative about processing marginal code.

Some of the warnings are actually for standards compliance. So the compiler guys have stepped up the way exceptions are handled. We now deal with placement delete correctly. We also have a new option on the compiler/GZ, where GZ are both upper case letters. And that guy turns on some extra checking per function call that you can do in your debug releases to verify the state of the stack pointer and what's on the stack to make sure that you're not doing any bad casts on function pointers, or to make sure nothing has overwritten a boundary [and corrupted the stack.]

Those are pretty exciting options. We'd like to, going forward, do a lot more work in that arena to help C++ programmers become a lot more productive.

MB/WS: Mike mentioned that we support the placement new and delete and vector new and delete.

MB/WS: We also did a lot of bug fixing on our template support.

MB/WS: Exactly. And ATL drove a lot of those because, as those of you who use ATL know, we use templates pretty aggressively there.

But as far as just generic conformance work, we didn't do a lot in this release. We're actually, for the most part, generally pretty happy with the level of conformance we have. We're well over 90 percent on any conformance that we've run, which is the highest on the Windows platform. We're pretty happy with that.

MB/WS: We can talk about ATL.

MB/WS: Let's talk about Rosie Perez.

MB/WS: I'm wondering if she's a C++ programmer or not.

MB/WS: She doesn't strike me as a Java kind of gal.

MB/WS: Yes. We've noticed.

MB/WS: Yes. we've noticed that.

We haven't mentioned much about ATL. We wanted to point out that ATL, you know, I touched on it just a second ago. But ATL has a lot of new support in the object wizard. There's lots of cool new features you can use to object wizard to add support to your ATL projects.

One of the most exciting is called the composite control. And the idea behind the composite control is that you can take a dialog and turn it into an (unintelligible) control. So you end up with composite control. Water ballet is ballet in the water.

It turns out that the dialog can host other OLE controls, can host HTML, can host whatever you're interested in using. ATL will go ahead and when you co-create that control, it actually brings up the dialog, handles all the focusing issues, handles all the ambient property issues, handles all the event routing issues and gets you off the ground with a real large size component that is generally going to be more monolithic than a single OLE control, and therefore a lot more flexible.

MB/WS: Going forward, I'll tell you, with this release, maybe in 5.0 I would have said, well, look, use ATL for OLE controls if you're going to be redistributing on the Web. They're much smaller, they're a little bit more flexible, they're a little bit faster because of the size.

If you're going to end up using any heavy scale features in MFC, such as database connectivity, go ahead and use MFC.

Starting with the 6.0 release, I think I'd change my advice and pretty much say, look, any time you write an OLE control from now on, go ahead and use ATL only. We'll create MFC support for creating controls, but we're probably not going to be interested in adding too much more functionality to it.

ATL provides a much better solution. It's a lot smaller, it's a lot more flexible. The object wizard now provides for light controls, which are, you know, slim down their interfaces and their ambient support to provide a much better footprint for controls that will be hosted in Internet Explorer, which is a great Web base story.

So I think that's sound advice for anyone who's starting a new project.

MB/WS: It's still tough.

MB/WS: In the long term we sort of envision MFC as a client side technology, whereas ATL is a component-oriented technology.

MB/WS: Indirectly through the composite control, sure.

MB/WS: In ATL there is a generic control containment technology that allows you to attach a control container to an HWND. And that's actually how we've implemented that composite control.

MB/WS: It's pretty pervasive in a development tool these days, that even as far as Access and Excel and Word and those kinds of desktop productivity apps, it's pretty common for them to be able to host controls because ActiveX controls are a pretty good component development story.

But as far as generic, things like Encarta or whatever, they would use ActiveX controls as part of their implementation, but wouldn't necessarily expose a way for you to generically host any ActiveX control.

MB/WS: C++

MB/WS: With MFC.

MB/WS: You got it.

MB/WS: We're on the next version, man.

MB/WS: That's right.

MB/WS: Faster, better, smaller.

MB/WS: That is a goal of the product. Exactly how that will pan out, we have yet to determine, because we're just entering the planning stages for those phases.

Mike Blazac and Walter Sullivan are developers on the Visual C++ team at Microsoft. We'll be back in two weeks, actually in three weeks here on the Dr. Dobbs Technetcast. Thanks for watching.

MB/WS: Thanks a lot.