Win32++
Moderator: Moderator Team
Win32++
Hi,
I have started to extend the current Media Player application (base\applications\mplay32).
The most annoying "problem" is the Win32 API and pure C. Yes, everything is possible with C & Win32 but it is a pain in the a**, really. If someone is looking for free SM, take a look at it (not even a String class ).
It would be cool if I could use C++ and Win32++:
In short, it could be described as "MFC very light".
http://win32-framework.sourceforge.net/index.htm
http://sourceforge.net/projects/win32-framework/
Would it be possible to officially use Win32++ in ReactOS? Even Microsoft uses C++/MFC (wordpad for example).
It could speed up the development for the userland applications (base\applications).
Please take a look at it and give it a try. It is really lightweight and closely coupled to the Win32 API (no cross-platform overhead, no dependencies). It consists basically of some header files (no extra dll or lib).
I have started to extend the current Media Player application (base\applications\mplay32).
The most annoying "problem" is the Win32 API and pure C. Yes, everything is possible with C & Win32 but it is a pain in the a**, really. If someone is looking for free SM, take a look at it (not even a String class ).
It would be cool if I could use C++ and Win32++:
In short, it could be described as "MFC very light".
http://win32-framework.sourceforge.net/index.htm
http://sourceforge.net/projects/win32-framework/
Would it be possible to officially use Win32++ in ReactOS? Even Microsoft uses C++/MFC (wordpad for example).
It could speed up the development for the userland applications (base\applications).
Please take a look at it and give it a try. It is really lightweight and closely coupled to the Win32 API (no cross-platform overhead, no dependencies). It consists basically of some header files (no extra dll or lib).
Re: Win32++
You should be able to use any Win32 application or framework in ROS, that works on Windows. Ideally, this is. Bundling is quite a different story. To bundle anything with ROS, we need to have access to its sources and to build it along our system. We are dedicated to limit the amount of third party code to absolute minimum, due to varied issues, like code correctness, changes, compiler issues. We also need to keep ReactOS code as small and as uniform as possible.
Re: Win32++
Yes, I understand the goals of ReactOSHaos wrote:You should be able to use any Win32 application or framework in ROS, that works on Windows. Ideally, this is.
Win32++ is open source and MIT licensed, no problem.Haos wrote:Bundling is quite a different story. To bundle anything with ROS, we need to have access to its sources and to build it along our system.
Yes, in general absolutely understandable. That's why I have not proposed Qt, GTK+, wxWidgets, etc. Win32++ is small and comparable with MFC. To be honest I have no interest to struggle with plain C and Win32 in my spare time. I have at best say 10h at week to do some "free" work. This time should be used as efficient as possible. Perhaps it is similar to other potential developers.Haos wrote:We are dedicated to limit the amount of third party code to absolute minimum, due to varied issues, like code correctness, changes, compiler issues. We also need to keep ReactOS code as small and as uniform as possible.
Please think about it. Haiku uses C++ everywhere. Increasing the development speed should be the most important.
Re: Win32++
We use C++ in many places, alas in some its getting us a big headache, especially when it comes to diferences between compilers (mainly MSVC and GCC).
Re: Win32++
No need for a big headache:Haos wrote:We use C++ in many places, alas in some its getting us a big headache, especially when it comes to diferences between compilers (mainly MSVC and GCC).
Even BCC 5.5 is supported!Supported Compilers and Integrated Development Environments (IDEs)
==================================================================
Win32++ supports the following:
* Borland Compiler Version 5.5
* Borland Developer Studio 2006
* Borland Turbo C++ 2006
* CodeBlocks
* Dev-C++
* MinGW GCC Compiler
* Visual Studio 6
* Visual Studio.net 2003
* Visual C++ Toolkit 2003
* Visual Studio.net 2005
* Visual Studio.net 2005 Express
* Visual Studio.net 2008
* Visual Studio.net 2008 Express
* Visual Studio.net 2010
BTW, to get it build with GCC and MSVC would be my problem.
Let's make a deal, if I implement mplay32 (as delivered with WinXP) with C++ and Win32++ it will not rejected because of this.
Any objections?
Re: Win32++
Since this is getting beyond my area of expertise, could you join our irc channel #reactos on irc.freenode.net and catch AmineKhaldi there? You will be able to discuss this issue with him.
Re: Win32++
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.
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.
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.
Petzold for C, Prosise for MFC. Just the first few chapters are enough. I can write MFC apps in Notepad, becauseI 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.I believe its important that we understand each line of our source code
That is the same for any runtime, any framework, any language - anything that makes things easier, you have to learn.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.
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.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.
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.
Re: Win32++
This is a bit of a weird case. Since this library is self-contained, theoretically it could just be bundled with the application that depends on it and statically linked in. The main question however is do we want to let Win32++ in, since once it's in for one application, we've set the precedent that it's allowable for others. This library is effectively just a wrapper around the core Win32 API (why do C++ devs like abstraction so much....), we'd need to see if anyone has a strong stance for it. And whether it even works in ReactOS to begin with.
Re: Win32++
@b4dc0d3r: To make it short, where is your contribution to ReactOS? BTW, please don't assume that peoples are "idiots" because you don't get the point.
That is my offer, if you have any doubts, no problem, really. But I need a decision, please.
My (very) long-term plan is to populate base\application application by application. It will be used by other applications too.Z98 wrote:This is a bit of a weird case. Since this library is self-contained, theoretically it could just be bundled with the application that depends on it and statically linked in. The main question however is do we want to let Win32++ in, since once it's in for one application, we've set the precedent that it's allowable for others.
Because it makes life easier.Z98 wrote:This library is effectively just a wrapper around the core Win32 API (why do C++ devs like abstraction so much....), ...
As I already stated, let me start with mplay32, if you like it, include it in ReactOS. But don't reject it because of C++ and Win32++.Z98 wrote:... we'd need to see if anyone has a strong stance for it. And whether it even works in ReactOS to begin with.
That is my offer, if you have any doubts, no problem, really. But I need a decision, please.
Re: Win32++
Please behave and adhere to forum rules.Dominik2 wrote:@b4dc0d3r: To make it short, where is your contribution to ReactOS? BTW, please don't assume that peoples are "idiots" because you don't get the point.
This is why I asked you to join irc, so a meeting can be set up. There are too many factors to consider before any decision could be made. We are awaiting your reply.Dominik2 wrote:As I already stated, let me start with mplay32, if you like it, include it in ReactOS. But don't reject it because of C++ and Win32++.
That is my offer, if you have any doubts, no problem, really. But I need a decision, please.
Re: Win32++
hmm, sounds not offensive to me, maybe a language problemHaos wrote:Please behave and adhere to forum rules.Dominik2 wrote:@b4dc0d3r: To make it short, where is your contribution to ReactOS? BTW, please don't assume that peoples are "idiots" because you don't get the point.
I was (later at Tuesday), AmineKhaldi explained the current C++ situation (http://www.reactos.org/wiki/C%2B%2B_TODO). Now I will do some investigations, maybe I can help to get C++ support in ReactOS.Haos wrote:This is why I asked you to join irc, so a meeting can be set up. There are too many factors to consider before any decision could be made. We are awaiting your reply.Dominik2 wrote:As I already stated, let me start with mplay32, if you like it, include it in ReactOS. But don't reject it because of C++ and Win32++.
That is my offer, if you have any doubts, no problem, really. But I need a decision, please.
Re: Win32++
@Dominik2
My reply was to your supporting documentation, not to you. Specifically, "The points made on the "Why not MFC page" are easily refuted. My comments were in context of that page. So yes, it was perhaps a language problem. You did not understand that I was referring to the project's goals and ambitions. The author wants to easily program for Windows using C++ without having to learn MFC or write wrappers around the Win32 API. This person is no idiot, and is providing a potentially useful framework. The argument on that page argues for idiots, those people who want to do things simply. There are lots of other more popular frameworks that accomplish the same goal.
Inclusion in ReactOS is still a terrible idea. If developers want to use it, they can deploy the Win32++ runtime libraries or equivalent with the application. Until a large number of applications are written using this, and I found none, inclusion in ReactOS makes absolutely no sense. When you have a list of reasonably mainstream applications which use this, maybe it makes sense. Otherwise, it's just a download away from everyone.
Inclusion implies support, and ReactOS devs have enough work with Win32. Introducing a framework to abstract the API may expose bugs which the developers can use to fix ReactOS, but this is best done by Win32++ developers testing their applications first, before even considering including it as a part of the OS. Some bugs exposed by Qt were fixed, and I expect any other library would expose other ways of doing the same thing.
My contribution is well documented, if you bothered to research before posting.
My reply was to your supporting documentation, not to you. Specifically, "The points made on the "Why not MFC page" are easily refuted. My comments were in context of that page. So yes, it was perhaps a language problem. You did not understand that I was referring to the project's goals and ambitions. The author wants to easily program for Windows using C++ without having to learn MFC or write wrappers around the Win32 API. This person is no idiot, and is providing a potentially useful framework. The argument on that page argues for idiots, those people who want to do things simply. There are lots of other more popular frameworks that accomplish the same goal.
Inclusion in ReactOS is still a terrible idea. If developers want to use it, they can deploy the Win32++ runtime libraries or equivalent with the application. Until a large number of applications are written using this, and I found none, inclusion in ReactOS makes absolutely no sense. When you have a list of reasonably mainstream applications which use this, maybe it makes sense. Otherwise, it's just a download away from everyone.
Inclusion implies support, and ReactOS devs have enough work with Win32. Introducing a framework to abstract the API may expose bugs which the developers can use to fix ReactOS, but this is best done by Win32++ developers testing their applications first, before even considering including it as a part of the OS. Some bugs exposed by Qt were fixed, and I expect any other library would expose other ways of doing the same thing.
My contribution is well documented, if you bothered to research before posting.
Re: Win32++
Thank you for your answer.b4dc0d3r wrote: My reply was to your supporting documentation, not to you. Specifically, "The points made on the "Why not MFC page" are easily refuted. My comments were in context of that page. So yes, it was perhaps a language problem. You did not understand that I was referring to the project's goals and ambitions. The author wants to easily program for Windows using C++ without having to learn MFC or write wrappers around the Win32 API. This person is no idiot, and is providing a potentially useful framework.
Sorry, but that is arrogant and wrong.b4dc0d3r wrote: The argument on that page argues for idiots, those people who want to do things simply.
As I stated before:b4dc0d3r wrote: There are lots of other more popular frameworks that accomplish the same goal.
It is really lightweight and closely coupled to the Win32 API (no cross-platform overhead, no dependencies). It consists basically of some header files (no extra dll or lib).
OK, you never looked at it. There are no runtime libraries. Please inform you next time.b4dc0d3r wrote: Inclusion in ReactOS is still a terrible idea. If developers want to use it, they can deploy the Win32++ runtime libraries or equivalent with the application. Until a large number of applications are written using this, and I found none, inclusion in ReactOS makes absolutely no sense. When you have a list of reasonably mainstream applications which use this, maybe it makes sense. Otherwise, it's just a download away from everyone.
Re: Win32++
Both of you, keep things civil.
Who is online
Users browsing this forum: No registered users and 23 guests