Yes, BOOL was the original MSVC++ boolean type, before ANSI C++ officially added "BOOL". MSVC++ with MS extensions is notorious for not compiling on other compilers, including other x86 compilers. It's no secret that MS has put many hacks in to C++ for the purposes of easing development on the Win32 platform. Any MS compiler will support these weird symbols.
VC.NET includes MFC7. It is basically MFC6 updated to support the newer Windows SDK features. MFC6 is almost 7 years old, and was targetted at the IE4 controls. MFC7 supports all the newer features found in the IE6 and COMCTRL6 (Common Controls), as well as GDI+. There are also great new classes, like CDHTMLDialog, which lets you use HTML pages instead of Resource Template to define Dialogs, but then handle their callbacks using C++. The compiler provides better ANSI C++ and better code generation. There's better STL support.
To sum it up, the C++ parts of VC.NET are not "also ran" additions.
That has to be a bug on their web page. The cell where the check for "Optimizing compiler" would be is not just blank, it looks to be missing all together. The edges around it are the wrong color.
The C++ compiler is "CL.exe". Its an all-in-one C/C++ compiler. C# compiler is "CS.exe".
My experience with VC.NET has been porting our existing VC6 MFC/C++ code to the.NET's VC7 compiler. Its C++ syntax is much stricter, and it comes with updated versions of the runtime libraries and headers that use stricter C++. From what I can tell, VC7 is 100% backwards compatible with VC6 code, from ActiveX component stubs to MFC to the Platform SDK.
I haven't used DirectX/Show, but I have read about them and they seem to use straight C and COM APIs. Given what I know about how VC7 (the true name for.NET) I'm going to guess that you should have no problem with it.
If you have some money to burn... get yourself a copy of the basic VisualC++.NET (the $109) suite and give it a try. At the very least, you'll get a great editor, debug, and tons of online help. If it turns out that it sucks, feel free to come back and flame me!
I still see a long life for C++ on Windows. The WTL is alive and strong, a great GUI library to work with. C++ is still the fastest language on Windows, no matter what MS marketting says about.NET.
.NET's C# is more or less a dead ringer for Java. If you know Java, you can pick up C# in a few hours, and being familiar with Win32 is a huge boon. You can call C Library methods directly from C#, and use all COM objects. I'm fairly certain that C++ COM objects will continue strong for years to come.
I work in the financial industry, where adoption of new technologies is very slow. It took us years to get off of X/Motif and onto MFC, and I don't see us moving to C#/.NET anytime for the forseeable future.
Interestingly enough, there's a HUGE "OpenSource" MFC programmer's community; way more Open than much of the stuff you see for UNIX (no license at all whatsoever public domain code.) One of the great things about having a single unified platform is that EVERYONE can share code equally. There's no GTK vs QT C++ vs C vs Python schism. Even VB COM objects are usable by all via ActiveX hosting (ugly but not hard to use in C++).
Visual C++.NET Standard 2003 Manufacturer: Microsoft Mfg Part #: 254-00257 Product Number: 301606
# Create Highly Tuned.NET-connected Applications and Components Use Managed Extensions to C++ and compiler support for optimized Microsoft Intermediate Language (MSIL) code generation. Incorporate Microsoft.NET Framework features including garbage collection, Windows Forms, and threading. Call unmanaged code using high-performance C++ interop technology.
# Create Highly Tuned Unmanaged Windows-based Applications and Components Write and compile unmanaged x86 code. Speed up your application or reduce its size with optimization options for a range of processors, including Whole Program Optimization, and support for Streaming SIMD Extensions (SSE) and Streaming SIMD Extensions 2 (SSE2) instruction sets.
Microsoft's own marketting blurb for the $109 Visual C++.NET package. Check it out yourself at CompUSA
Personally, I'm not a fan of any sort of GUI Form editor. I tend to create my forms by hand, in my code, and position them dynamically using Layout Managers, the sort used in Motif and Java/AWT.
Whats sad is that most people use GUI Form editors as a litmus test for a "good, complete" enviroment for "power developers". I think Form editors should be a crutch for beginners (to GUI programming altogether), until they learn how to visual a layout in their minds.
Forms are just that - Forms, for simple Dialog boxes. The trend in UI design has been moving away from "Dialog Controls" and OK buttons for years now. Forms are almost becoming irrelevant and are being replaced with floating tool palettes and web-page like UIs surrounding very powerful "Views" designed to interact with specific kinds of data.
The only GUI package I know of that is intended for this sort of design is WTL (Windows Template Library), which happens to be free from Microsoft.
THe thing about the cost on developing windows is not 100% true. You can download Microsoft's command-line C/C++/C# compilers for free, along with SDK's for developing Internet apps, GUI apps, database apps, and much much more.
You have to pay for their IDE, debugger and for a local copy of the manuals, BUT you can do a whole lot for free. Don't forget either that the basic Visual C++/C# package is only $99.
There's always GCC/Cygwin. You can install the free MS SDK, and then use any Cygwin development tools you like.
Thing is, most windows developers actually LIKE Visual C++. It's really a great environment once you customize it (far less so than you need to customize Emacs).
Slashdot Mirror
Try Emacs ! Once you get your key bindings right, it's really a fabulous editor. Lisp grows on you FAST.
VC.NET includes MFC7. It is basically MFC6 updated to support the newer Windows SDK features. MFC6 is almost 7 years old, and was targetted at the IE4 controls. MFC7 supports all the newer features found in the IE6 and COMCTRL6 (Common Controls), as well as GDI+. There are also great new classes, like CDHTMLDialog, which lets you use HTML pages instead of Resource Template to define Dialogs, but then handle their callbacks using C++. The compiler provides better ANSI C++ and better code generation. There's better STL support.
To sum it up, the C++ parts of VC.NET are not "also ran" additions.
The ones that do are "Jackasses" and you need to impose your iron will on them, like any secretary or executive.
That has to be a bug on their web page. The cell where the check for "Optimizing compiler" would be is not just blank, it looks to be missing all together. The edges around it are the wrong color.
My experience with VC.NET has been porting our existing VC6 MFC/C++ code to the .NET's VC7 compiler. Its C++ syntax is much stricter, and it comes with updated versions of the runtime libraries and headers that use stricter C++. From what I can tell, VC7 is 100% backwards compatible with VC6 code, from ActiveX component stubs to MFC to the Platform SDK.
I haven't used DirectX/Show, but I have read about them and they seem to use straight C and COM APIs. Given what I know about how VC7 (the true name for .NET) I'm going to guess that you should have no problem with it.
If you have some money to burn... get yourself a copy of the basic VisualC++.NET (the $109) suite and give it a try. At the very least, you'll get a great editor, debug, and tons of online help. If it turns out that it sucks, feel free to come back and flame me!
I work in the financial industry, where adoption of new technologies is very slow. It took us years to get off of X/Motif and onto MFC, and I don't see us moving to C#/.NET anytime for the forseeable future.
Interestingly enough, there's a HUGE "OpenSource" MFC programmer's community; way more Open than much of the stuff you see for UNIX (no license at all whatsoever public domain code.) One of the great things about having a single unified platform is that EVERYONE can share code equally. There's no GTK vs QT C++ vs C vs Python schism. Even VB COM objects are usable by all via ActiveX hosting (ugly but not hard to use in C++).
Whats sad is that most people use GUI Form editors as a litmus test for a "good, complete" enviroment for "power developers". I think Form editors should be a crutch for beginners (to GUI programming altogether), until they learn how to visual a layout in their minds.
Forms are just that - Forms, for simple Dialog boxes. The trend in UI design has been moving away from "Dialog Controls" and OK buttons for years now. Forms are almost becoming irrelevant and are being replaced with floating tool palettes and web-page like UIs surrounding very powerful "Views" designed to interact with specific kinds of data.
The only GUI package I know of that is intended for this sort of design is WTL (Windows Template Library), which happens to be free from Microsoft.
THe thing about the cost on developing windows is not 100% true. You can download Microsoft's command-line C/C++/C# compilers for free, along with SDK's for developing Internet apps, GUI apps, database apps, and much much more. You have to pay for their IDE, debugger and for a local copy of the manuals, BUT you can do a whole lot for free. Don't forget either that the basic Visual C++/C# package is only $99. There's always GCC/Cygwin. You can install the free MS SDK, and then use any Cygwin development tools you like. Thing is, most windows developers actually LIKE Visual C++. It's really a great environment once you customize it (far less so than you need to customize Emacs).