On August 21, 2003 08:23 pm, Steven Edwards wrote:
It took a little bit of work but I managed to get a *.dsw for wrc to work.
Changelog: WRC Porting fix. Move non-standard Language IDs
Alexandre,
We still have a few (hard to remove) "#ifdef __WINESRC__" in our headers. We all agree they should be removed, but they are not trivially removable right now. I say we should move all such extensions to a "wine/internal.h" header. This will accomplish a few things: -- make the task of compiling with other headers a lot easier. This will further result in more portability and header fixes for our standard headers, which is a Good Thing(TM). -- the "wine/internal.h" include should be included only from .c files, thus explicitly marking such offenders, and providing a list of things that need to be addressed. -- the "wine/internal.h" header itself will serve as a quick "TODO" for people interested in fixing these. The last two points will also make it easier to see where we're using undesirable extensions.
Whatdayasay?
"Dimitrie O. Paun" dpaun@rogers.com writes:
We still have a few (hard to remove) "#ifdef __WINESRC__" in our headers. We all agree they should be removed, but they are not trivially removable right now. I say we should move all such extensions to a "wine/internal.h" header. This will accomplish a few things: -- make the task of compiling with other headers a lot easier. This will further result in more portability and header fixes for our standard headers, which is a Good Thing(TM). -- the "wine/internal.h" include should be included only from .c files, thus explicitly marking such offenders, and providing a list of things that need to be addressed. -- the "wine/internal.h" header itself will serve as a quick "TODO" for people interested in fixing these. The last two points will also make it easier to see where we're using undesirable extensions.
Whatdayasay?
I don't think the problem is so much with internal definitions, pretty much all of them are gone at this point. The problem is really with extensions that we want to make available to applications too, like the extra languages. We could have a wine/extensions.h header, but I'm not convinced we can really move everything there without creating a big mess.
--- Alexandre Julliard julliard@winehq.com wrote:
I don't think the problem is so much with internal definitions, pretty much all of them are gone at this point. The problem is really with extensions that we want to make available to applications too, like the extra languages. We could have a wine/extensions.h header, but I'm not convinced we can really move everything there without creating a big mess.
So where should these IDs go? Once I send the correct patch that is.
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
On August 22, 2003 12:53 am, Alexandre Julliard wrote:
I don't think the problem is so much with internal definitions, pretty much all of them are gone at this point. The problem is really with extensions that we want to make available to applications too, like the extra languages. We could have a wine/extensions.h header, but I'm not convinced we can really move everything there without creating a big mess.
What sort of mess do you forsee? All I expect is that we'll have a series of patches that will (a) move one such extension to the new header, and (b) explicitly add the include to all the affected .c files.
I think this will make the mingw work a lot simpler. And in general, it will make things a lot more explicit in terms of what is standard and what is a Wine extension, and this is good.
Do we get the go ahead? :)
"Dimitrie O. Paun" dpaun@rogers.com writes:
I think this will make the mingw work a lot simpler. And in general, it will make things a lot more explicit in terms of what is standard and what is a Wine extension, and this is good.
Do we get the go ahead? :)
No, actually the more I think about it the less I like it. The problem with that approach is that if an app uses wine/extensions.h, not only you can't it build under Windows without somehow obtaining the Wine header first, but once you compile it it will use all sorts of extensions that won't work under Windows.
IMO it's better to leave the extensions in the normal headers and make the code deal with missing definitions in case you are building under Windows. So instead of importing the definition of say LANG_GAELIC from some Wine header, you wrap that code in a #ifdef LANG_GAELIC, and then the app can build and run correctly both on Windows and Wine. We could also wrap the extensions with #ifndef WINE_NO_EXTENSIONS in our headers so that you can define that symbol when building under Wine to make sure your code is portable.
On Friday 22 August 2003 18:12, Alexandre Julliard wrote: ...
IMO it's better to leave the extensions in the normal headers and make the code deal with missing definitions in case you are building under Windows. So instead of importing the definition of say LANG_GAELIC from some Wine header, you wrap that code in a #ifdef LANG_GAELIC, and then the app can build and run correctly both on Windows and Wine. We could also wrap the extensions with #ifndef WINE_NO_EXTENSIONS in our headers so that you can define that symbol when building under Wine to make sure your code is portable.
I don't know much about wine extensions. I just wonder why wine needs such things. In the past there were problems when wine didn't behave like windows and these extensions are problematic too.
I have to apologize, because my lack of knowledge in this regard, but there are multilingual versions of Windows too. Why not do it like Microsoft does? Is this possible?
Regards Gerold
On Sun, 24 Aug 2003, Gerold J. Wucherpfennig wrote: [...]
I have to apologize, because my lack of knowledge in this regard, but there are multilingual versions of Windows too. Why not do it like Microsoft does? Is this possible?
From what I gathered reading this thread, we do it like Microsoft dos,
but we support so extra languages.
This is what causes problems when an application includes resources for languages not known by the Microsoft headers... unless it is done so as not to include such resources when compiled on Windows.
On August 22, 2003 12:12 pm, Alexandre Julliard wrote:
No, actually the more I think about it the less I like it. The problem with that approach is that if an app uses wine/extensions.h, not only you can't it build under Windows without somehow obtaining the Wine header first, but once you compile it it will use all sorts of extensions that won't work under Windows.
IMO it's better to leave the extensions in the normal headers and make the code deal with missing definitions in case you are building under Windows. So instead of importing the definition of say LANG_GAELIC from some Wine header, you wrap that code in a #ifdef LANG_GAELIC, and then the app can build and run correctly both on Windows and Wine. We could also wrap the extensions with #ifndef WINE_NO_EXTENSIONS in our headers so that you can define that symbol when building under Wine to make sure your code is portable.
[Sorry for the late reply, it got stuck somewhere in my reply queue :)]
I agree with this, but the two issues are completely orthogonal. One deals with how we organize extensions, one on how to use them. I am 100% with you that a portable implementation is better -- it is in fact the same pattern adopted by 'configure'. However, this says nothing about where to place such extensions. In fact, I would argue that placing such extension in explicitly designated headers will actually help Winelib developers. For one, it will make it a lot more explicit when they will have to use the portable pattern you were advocating. Otherwise, if development happens user Winelib, this can be easily missed. Moreover, it allows projects to easily enforce (by giving them the means to trivially check were Wine extensions are being used) certain policies about when/where/how Wine extensions are acceptable.
For portability, people will have to simply do: #ifdef __WINE__ #include <wine/extensions.h> #endif
just like they do with HAVE_XXX_H tests. It fits in rather well, no?
"Dimitrie O. Paun" dpaun@rogers.com writes:
I agree with this, but the two issues are completely orthogonal. One deals with how we organize extensions, one on how to use them. I am 100% with you that a portable implementation is better -- it is in fact the same pattern adopted by 'configure'. However, this says nothing about where to place such extensions. In fact, I would argue that placing such extension in explicitly designated headers will actually help Winelib developers. For one, it will make it a lot more explicit when they will have to use the portable pattern you were advocating. Otherwise, if development happens user Winelib, this can be easily missed. Moreover, it allows projects to easily enforce (by giving them the means to trivially check were Wine extensions are being used) certain policies about when/where/how Wine extensions are acceptable.
For portability, people will have to simply do: #ifdef __WINE__ #include <wine/extensions.h> #endif
just like they do with HAVE_XXX_H tests. It fits in rather well, no?
I don't agree that the issues are orthogonal, I think that how we organize the extensions very much depends on how we want people to use them. Also I think your approach does not encourage the right pattern, it actually suggests using #ifdef __WINE__ everywhere.
I think the main question is whether or not we want to encourage use of the extensions. If we want to encourage it, then they should be in the default headers; if you need some magic incantation to make them available nobody will bother. Now, if we'd rather encourage portable code that doesn't use extensions, then IMO we shouldn't export them at all, and let people who really want them go to the trouble of copying them from Wine internal headers.
There's also the issue of backwards compatibility; many of the extensions are for things that aren't documented by Microsoft at this point, but that may become documented one day. If that happens and the extension is already in the standard headers then it's completely transparent; but if it's in wine/extensions.h then we'll have trouble keeping everything in sync.
On August 26, 2003 12:35 am, Alexandre Julliard wrote:
I think the main question is whether or not we want to encourage use of the extensions. If we want to encourage it, then they should be in the default headers; if you need some magic incantation to make them available nobody will bother. Now, if we'd rather encourage portable code that doesn't use extensions, then IMO we shouldn't export them at all, and let people who really want them go to the trouble of copying them from Wine internal headers.
Well, first off, it's not clear that we provide any worthwhile extensions to warant all the complications. In fact, due to the scattered nature of said extensions, I don't even have a good idea of what extensions we have and if they are worthwhile. BTW, any user (that is app developer) will be in the same situation. Second, I don't think a simple include qualifies to the rank of magic incantation -- it's the least obtrusive way of letting people know they are using something non-standard. Thirdly, the backwards compatibility you mention is a big can of worm, and I think it's a bit of a red herring -- binary compatibility will most likely be busted anyway, what are the chances we're going to pick the same binary value as MS?
I have to admit I play the devil's advocate role in this debate. From my POV the biggest benefit is that we'll have a _simple_ rule for our headers: keep them as close as possible to the MS' one. Not a simple task, and experience has shown that the simple the rule/principle, the easier to understand and implement. We've learned the hard way many atimes that playing smart does not pay. There are places where it's worth doing, but it's far from clear that we have such a compelling reason to break this principle in this case.
"Dimitrie O. Paun" dpaun@rogers.com writes:
Well, first off, it's not clear that we provide any worthwhile extensions to warant all the complications. In fact, due to the scattered nature of said extensions, I don't even have a good idea of what extensions we have and if they are worthwhile. BTW, any user (that is app developer) will be in the same situation. Second, I don't think a simple include qualifies to the rank of magic incantation -- it's the least obtrusive way of letting people know they are using something non-standard. Thirdly, the backwards compatibility you mention is a big can of worm, and I think it's a bit of a red herring -- binary compatibility will most likely be busted anyway, what are the chances we're going to pick the same binary value as MS?
For things we invent ourselves the chances are pretty small, but most extensions are for undocumented stuff, where the values/function names/etc. are defined by MS already, only they are not part of the normal headers; winternl.h is a good example of that.
I have to admit I play the devil's advocate role in this debate. From my POV the biggest benefit is that we'll have a _simple_ rule for our headers: keep them as close as possible to the MS' one. Not a simple task, and experience has shown that the simple the rule/principle, the easier to understand and implement. We've learned the hard way many atimes that playing smart does not pay. There are places where it's worth doing, but it's far from clear that we have such a compelling reason to break this principle in this case.
The problem is that the "as close as possible" rule also implies not creating new headers; so either way we are breaking the rule, and IMO it's better to keep a few extra definitions in the normal headers, close to where they belong (for instance the extra LANG_* constants next to the other LANG_ stuff) than splitting them to a separate header.
--- Alexandre Julliard julliard@winehq.org wrote:
The problem is that the "as close as possible" rule also implies not creating new headers; so either way we are breaking the rule, and IMO it's better to keep a few extra definitions in the normal headers, close to where they belong (for instance the extra LANG_* constants next to the other LANG_ stuff) than splitting them to a separate header.
The LANG_ example may be pointless anyway as most those IDs seem to valid for the PSDK. I only had MS_VC SP3. Anyway I am going to be doing more testing with Visual Stdio to try and get some of these dlls ready to merge with ReactOS but I need a perl guru's help to fix the include order on the headers. What do we need from this script? Besides fixing the include order in the .c files does it need to check the headers and see where we include other headers the PSDK doesnt?
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
-
Alexandre Julliard -
Dimitrie O. Paun -
Francois Gouget -
Gerold J. Wucherpfennig -
Steven Edwards