Windows programming- help putting in order some ideas

[KansaiRobot]

First, a bit of background. I have been programming in C and C++ (also once objective -c) mainly on linux or with embedded platforms, so my experience with windows is limited. Yes, I have in the past made programs in windows, mainly C++/CLI with studio express, but not in a methodical way so my concepts are a little bit disorganized. I would appreciate if someone confirm or correct (true or false and an explanation) the following (also apologies if I say something outrageous)

In windows:

1) You can program in C++ using either CLI or MFC

2) MFC is not included in the express editions of visual studio (including the latest community 2015)

3) MFC is older than CLI

4)It is preferable to use CLI than MFC because it deals directly with .NET

5) MFC is ...I dont know how to put it... more bothersome to program than using CLI...

6) All this discussion becomes void if I just choose to program in C sharp.

-------------
I have other questions too.
If I want to do some network programming, I have to use winsock, right??

And another important question:
What is the difference in programming for 32-bit and for 64-bit??

Can I program for 64-bit on a 32-bit windows 7 machine. (If not I can take hold of a 64-bit windows 10 machine I think).

Is the tool (visual studio) the same?

Any other thing I have to take into account for programming in 64-bit?

Sorry for the long post but I would really appreciate any help you can give me

[stahta01]

I am answering the questions with (CLI) meaning Common Language Infrastructure.
And, (MFC) meaning Microsoft Foundation Class Library.

Note: There is un-managed C++ instead of managed C++ (I think managed C++ is the same as CLI; but, I am NOT sure).

1. False; there are other things than MFC and CLI you can program C++ in on Windows!
2. I thought one of the community editions had MFC in it; but, I might be wrong.
3. I agree MFC is older than Common Language Infrastructure.
4. No idea of the right answer.
5. No idea of the right answer.

I suggest looking at MSys2 because you seem to think MS Visual Studio is it on Windows.
MSYS2 installer

You can do 64 bit on a 32 bit machine when using MSys2 GCC.

Tim S.

[freddie]

With Windows, the lowest level interface to it is the Windows Application Programming Interface (API). There may be something of a very rough analogy to it in the *nix world to XLib, with the important exception that included as part of the Win Api is a Window Manager, which is built right into the interface the Api provides. What all this means is that all of the functionality of Windows including the creation of complex GUI apps is directly accessable in pure low level C once one has the libraries and headers, which are available as a seperate download without Visual Studio or any of the high powered development products. Once you have the libraries and headers you could write Dennis Ritchie's classic "Hello, world!" program in C or C++ with any text editor (Notepad.exe in Windows, for one), compile and link it, creating either a 32 bit executable or 64 bit. The distinction between 32 bit and 64 bit is completely transparent. If you built the above described Hello, World program with a 32 bit compiler you would have a 32 bit binary; if built with a 64 bit compiler then a 64 bit binary.

In the 1990s folks started building Windows 'Class Frameworks' using C++. What these do is encapsulate the raw low level Api within C++ classes. Very early ones were MFC by Microsoft and OWL (Object Windows Library) by Borland. Since then Cross Platform Toolkits have become popular, of course then there's .NET, etc. These have all been widely adopted and found useful by many folks. However, they all sit upon well documented lower level interfaces which can be used directly.

[freddie]

Also, as the other poster said, there are other ways of developing Windows programs even using many other non C/C++ languages. For many years I used PowerBASIC, which allowed me to access the Windows Api directly, and write as low level code as I wished - even inline assembler. So you aren't even limited to C or C++.

[freddie]

All this discussion becomes void if I just choose to program in C sharp.

A better way of putting it would be that the above represents a decision to use the .NET Class Framework (a class based encapsulation of the Windows Api) through the C# programming language.

[freddie]

Can I program for 64-bit on a 32-bit windows 7 machine. (If not I can take hold of a 64-bit windows 10 machine I think).

Yes, but there are several considerations.

I'm almost certain that several years ago I tested this with GCC. For your information, there is a port of GCC to Windows known as MinGW, and there are several offshoots or branches of that. Anyway, I installed the Win32/64 setup of GCC (TDM-GCC-64 I believe) on a 32 bit OS and specified the -64 switch to generate 64 bit code. The resulting binary wouldn't run on that x86 box which created the x64 binary. However, transferring it to my x64 Win 7 box caused it to run fine.

Now that is with the GCC toolchain. I do not believe I specifically tested this with MS products. Although I have Visual Studio Community 2015 (VC19) on my HP Envy Win 10 x64 laptop, my main coding environment is VC15 from Visual Studio 2008 on a Dell M6500 Win 7 x64 box. With that setup you have to explicitely tell the installer to install the 64 bit build tools when you install Visual Studio. The default - in that version anyway - was to just install the 32 bit build chain. Now I'm not 100% certain the installer would install the 64 bit tool chain and import libraries on a 32 bit box. I'm just not sure. It might and it might not. If it would, then you would be able to do what I stated above with GCC.

Fact is, Windows code should be written to be x86/x64 agnostic. The main way this has affected me in the Windows coding I do involves the GetWindowLongPtr() and SetWindowLongPtr() functions.