Re: winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.
On Tue, Feb 17, 2009 at 12:51 PM, Francois Gouget <fgouget(a)free.fr> wrote:
---
I moved them after the windows.h include though in practice the needed winnt.h has already been included by the time we include winetest.h. So maybe windows.h should be nuked altogether...
Conversely maybe using windows.h usage should be fixed and used more often. Wine is an oddball when it comes to win32 program with the excessive lengths it goes to, to avoid using windows.h. I am starting to think even avoiding it internally like we do causes more harm than good as far as being source compatible with MSVC. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
"Steven Edwards" <winehacker(a)gmail.com> wrote:
Conversely maybe using windows.h usage should be fixed and used more often. Wine is an oddball when it comes to win32 program with the excessive lengths it goes to, to avoid using windows.h. I am starting to think even avoiding it internally like we do causes more harm than good as far as being source compatible with MSVC.
The reason why we avoid windows.h inclusion in Wine is compilation time by avoiding inclusion of all-in-one headers windows.h does. It's always a good programming practice to include only those .h files that are really needed, inclusion of windows.h usually shows the ignorance and lack of knowledge of a programmer. -- Dmitry.
On Tue, Feb 17, 2009 at 10:40 PM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
The reason why we avoid windows.h inclusion in Wine is compilation time by avoiding inclusion of all-in-one headers windows.h does. It's always a good programming practice to include only those .h files that are really needed, inclusion of windows.h usually shows the ignorance and lack of knowledge of a programmer.
I've agreed with the logic and the reasons behind it for the Wine libraries. My point was that we already avoid it more than enough in libraries, and maybe its a good thing after far as winelib goes to insure the apps in the programs directory always do include windows.h so that whenever someone does a true winelib port they don't have to make unnecessary changes just to please Wine. Maybe someone should drop those Chromium guys a note as they seem to include windows.h in a lot of places.... -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
"Steven Edwards" <winehacker(a)gmail.com> wrote:
I've agreed with the logic and the reasons behind it for the Wine libraries. My point was that we already avoid it more than enough in libraries, and maybe its a good thing after far as winelib goes to insure the apps in the programs directory always do include windows.h so that whenever someone does a true winelib port they don't have to make unnecessary changes just to please Wine.
Is there a specific problem you are trying to point out indirectly, or that's just a speculation?
Maybe someone should drop those Chromium guys a note as they seem to include windows.h in a lot of places....
That's a commeon practice among windows programmers, want to mail all of them? There is a good prediction where they will tell you to go. -- Dmitry.
On Wed, Feb 18, 2009 at 3:16 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
Is there a specific problem you are trying to point out indirectly, or that's just a speculation?
I was just thinking perhaps we need a better way of making sure the headers match up with the PSDK. I know we can do a MSVC configuration for Windows headers and libraries for building winetest but I've not looked at how well it works recent. The last time I attempted building any major part of Wine with the PSDK in the include path first the results were not very pleasing. I'll add reviewing this to the list of hundreds of other things I mean to look at when I have the time ;)
Maybe someone should drop those Chromium guys a note as they seem to include windows.h in a lot of places....
That's a commeon practice among windows programmers, want to mail all of them? There is a good prediction where they will tell you to go.
Hehe I am sure ;) -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Tue, 17 Feb 2009, Steven Edwards wrote:
On Tue, Feb 17, 2009 at 12:51 PM, Francois Gouget <fgouget(a)free.fr> wrote:
---
I moved them after the windows.h include though in practice the needed winnt.h has already been included by the time we include winetest.h. So maybe windows.h should be nuked altogether...
Conversely maybe using windows.h usage should be fixed and used more often. Wine is an oddball when it comes to win32 program with the excessive lengths it goes to, to avoid using windows.h. I am starting to think even avoiding it internally like we do causes more harm than good as far as being source compatible with MSVC.
My remark was not so much about including windows.h rather than winfoo.h, but about including it in winetest.h when the parent C file has already included the winxxx.h files it needs. That is, in Wine it seems we have a policy to put include statements primarily in the C files, rather than in private header files. Also: * I don't see what depends on windows.h in winietest.h (besides my newly added annotations). * if I remember correctly, removing this include did not cause any warning or compilation error (even with my newly added annotations). But maybe it's different if you compile with MinGW or MSVC (in which case Wine's headers should be fixed). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.
On Wed, Feb 18, 2009 at 5:20 AM, Francois Gouget <fgouget(a)free.fr> wrote:
My remark was not so much about including windows.h rather than winfoo.h, but about including it in winetest.h when the parent C file has already included the winxxx.h files it needs. That is, in Wine it seems we have a policy to put include statements primarily in the C files, rather than in private header files.
Also: * I don't see what depends on windows.h in winietest.h (besides my newly added annotations). * if I remember correctly, removing this include did not cause any warning or compilation error (even with my newly added annotations). But maybe it's different if you compile with MinGW or MSVC (in which case Wine's headers should be fixed).
Right, I don't disagree with the change, I was more just thinking out loud. I agree it does not need to be in that header, I just think we should not avoid using windows.h in the programs. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
participants (3)
-
Dmitry Timoshkov -
Francois Gouget -
Steven Edwards