This is a terrible idea. If you want to make your own application using this framework, then please do so and report any bugs. It is open source, so as long as someone is willing to debug the problems, some Win32 issues may be found and fixed.
For official ReactOS development, all programming should be in a standard language and/or framework. C is the lowest common denominator, since all of the API documentation is in C. C++ is certainly possible, and many Windows applications are C++. Some are in MFC, but not nearly as many as I would expect. The C runtime, C++ runtime, and MFC runtime, are all expected to exist on Windows, at least starting with XP. So, for the last decade any of these is "standard" Windows development.
Any other framework, whether it is Qt, wxWidgets, Win32++, or anything else, should not be part of the core ReactOS. It looks a *lot* like MFC, just like initial versions of wxWindows did. And wxWindows evolved and became a separate entity, renamed wxWidgets.
The points made on the "Why not MFC page" are easily refuted.
MFC has wizards to help develop code, and the result is not obviously understandable, unless you read a good MFC book,
http://www.amazon.com/Programming-Windo ... 1572316950 After that, Jeff Prosise gives you everything you need to know to fix or adjust your code. So Win32++ wants you to be able to understand it quickly. The opposite of reading a large book. MFC fails the test because it is so vast. What is wrong with understanding only the parts you need to understand? I know maybe half of it, and moved back to C, then to C#. But I can still write MFC apps if needed. Why do you need to know the whole thing to write simple apps? This is a terrible argument.
You don't want to learn a lot of new things to get started, but MFC requires knowing a lot> No, actually you can be completely ignorant, follow the wizards, and have something working quickly. Visual Studio is expensive? Well, try Visual Studio Express. It's free. Limited, but it can get the "simple app" job done easily.
I believe its important that we understand each line of our source code
Petzold for C, Prosise for MFC. Just the first few chapters are enough. I can write MFC apps in Notepad, because
I believe its important that we understand each line of our source code
. Of course, I can write the same in x86/x64 assembly. You set up the function calls and call them. You have to know what you are calling.
The problem for beginners with libraries like WTL and MFC is that they are likely to end up with source files that includes lines of code that they don't actually understand.
That is the same for any runtime, any framework, any language - anything that makes things easier, you have to learn.
In my case, after using MFC for a while I realized that I didn't thoroughly understand the code I was writing. I wasn't happy with that so went back to working with the windows API directly. This library was the result.
I read the Prosise book and understood exactly what I was writing. Win32++ author decided to write a wrapper, not unlike the initial wxWindows library, so that he understood what was going on under the hood.
Bottom line - standard developers are not going to want to learn yet another library/framework to develop in. If you have a desire to use this library, by all means do so. There is no reason to make it standard to ReactOS. If you make an application, install the runtime with the installer, just like MFC used to be distributed with installers in Windows 95. If it catches on, Microsoft will include it, and ReactOS will as well. Otherwise... you can include it with the installer, so what's the point, exactly?
I will answer that. You found something you like. Go ahead and use it, write applications in it, and report bugs. Same as every other framework/library.
If I have not managed to get my point across, consider this: Windows does not include Win++. Therefore, there is no reason ReactOS would include it, natively. Again, include it in an installer or .ip distribution, or however you want to. But it is not a core Windows library as MFC is, or as the C runtime is. So it will not be included any time soon.
). 