Quote:Original post by Anonymous Poster

Quote:Original post by Extrarius
The WinAPI sucks

Based on what criteria?

The Win32 API doesn't suck. Just because you don't like it doesn't mean you should go around making generalizations. Your comment simply demonstrates that you haven't had much experience with APIs that REALLY suck.

Perhaps the Win32 API isn't the worst API ever conceived. However, considering there are vastly better in every way options, anyone who uses the WinAPI for anything but maintenance if legacy code is insane. INSANE. Or stupid.

Quote:Original post by Ancient Spirit
By the way, when I say Visual C++ and MFC... Are those 2 different things?

Very. Visual C++ is the brand name for Microsoft's integrated development environment (IDE) for C++. Visual C++ is a part of Visual Studio, which has evolved over the years to let the various "Visual" products share components such as the text editor. The compiler is known as Microsoft C++ x, where x is the version number (currently at 8.0).

The Microsoft Foundation Classes (MFC) are a collection of C++ classes and preprocessor code (and macros) that greatly simplify the process of writing Win32 GUI code. MFC has shipped with Visual C++ for at least 12 years; I first encountered them both in Visual C++ 1.52, which was my first C++ compiler.

Quote:Original post by Ancient Spirit
So basically I can use C++ for the class design and C# only for the GUI?

Yes, you can. You have two alternatives:

You can write an "unmanaged" C++ DLL (with C interfaces, naturally) which is made accessible to C# via interop. This is best if you are going to expose a limited number of APIs from your C++ DLL to C#, and communication is simple: pass native type (int, byte arrays) arguments to the DLL, retrieve integer type return values.

You can also write a managed assembly in C++/CLI, placing the interoperability layer between managed and unmanaged code within your assembly. This has the advantage of making the overall assembly much easier to use, as well as making it available to the full range of .NET languages (C#, VB.NET, F#, Nemerle, PERL.NET, COBOL.NET, FORTRAN.NET, IronPython, etc).

Quote:I have managed to combine fortran and C\C++ code and some ASM code with it as well.

The mechanisms are very different. First, all of the above expose C declarations (you can pass C++ declarations because name mangling makes them unrecognizable). Secondly, it sounds like you linked them all into a single binary file. Using the .NET assembly-based method, each language can generate its own assembly (produce code) and any other language can use it (consume code).

It's a very different approach.

Borland C++ Builder. The VCL is amazing, although it is a 'wrapper' for the Win API, you can still do *a lot* with it.

Old Borland Builder compilers lost integrated debugging ability after your project got too big. Is this still an issue?

(Borland Builder executables were, and most likely still are, 30% bigger than exactly equivalent MS built executables, if that is an issue for perusers of this thread. But the VCL / RAD capabilities were fantastic.)

Quote:Original post by Anonymous Poster
(Borland Builder executables were, and most likely still are, 30% bigger than exactly equivalent MS built executables, if that is an issue for perusers of this thread. But the VCL / RAD capabilities were fantastic.)

Who would seriously have a problem if an executable is ~30% bigger? 130 kB vs 100? 1300 kB vs 1000? That kind of problems are located between the ears of certain progammers.

Win32 API was the main reason I managed to be able to do stuff in VB 6 back at the time. The combination of the two was powerful.

But now with .NET ... things have changed. You can program your solution in many languages (C#, C++, and VB at the same time), even though I've never had to do that (yet).

So to answer your initial question:
IMHO if you want to know what make things "tick", go with the Win32 API (not MFC). If you need programs made fast and easy go with .NET.

Hope this help