cc-ing WINE list in case its also present in the WINEHQ CVS this line: typedef const PROPSHEETPAGEA *LPCPROPSHEETPAGEW; should (I believe) be this line: typedef const PROPSHEETPAGEW *LPCPROPSHEETPAGEW;
If this is a bug, can someone fix it? If its not, can someone explain why this construct is present (it looks very wierd to mix an A structure and a W structure in this typedef)
On December 3, 2003 06:47 am, Jonathan Wilson wrote:
typedef const PROPSHEETPAGEA *LPCPROPSHEETPAGEW; should (I believe) be this line: typedef const PROPSHEETPAGEW *LPCPROPSHEETPAGEW;
If this is a bug, can someone fix it?
It's a bug in your headers, and it's not present in the Wine headers (one again, why aren't you guys using our headers?)
On Wed, 2003-12-03 at 08:46, Dimitrie O. Paun wrote:
On December 3, 2003 06:47 am, Jonathan Wilson wrote:
typedef const PROPSHEETPAGEA *LPCPROPSHEETPAGEW; should (I believe) be this line: typedef const PROPSHEETPAGEW *LPCPROPSHEETPAGEW;
If this is a bug, can someone fix it?
It's a bug in your headers, and it's not present in the Wine headers (one again, why aren't you guys using our headers?)
We're still working out a plan for sharing headers; unfortunately it's not as easy as just using Wine's headers.
-Vizzini
On December 3, 2003 10:57 am, Vizzini wrote:
We're still working out a plan for sharing headers; unfortunately it's not as easy as just using Wine's headers.
I know things are not always as easy as they seem, and I must apologize for reopening this issue, but there's something I miss. Namely, we're aiming to be MS compatible, so in theory it _should_ be as simple as just using Wine's headers.
I am aware we're not there yet, but I think we're doing OK. Most of the ifdefs in our header files for __WINESRC__ are to restrict the headers. That is, we simply don't allow some things to be used in our source. This should be no problem for you, no? If there are incompatibilities, we are very interested in fixing. In fact, the Winelib porting effort I started a year ago is aimed (in part) at finding problems with our headers.
Also, Steven has tried to multiple times to explain that you guys felt the need to build your own headers because ours are not perfect. I am sorry to say, this makes no sense to me. First, as you can see, it's not the case that if you're building them yourself, they are going to be perfect. Second, you're duplicating an enormous amount of effort that could be expanded in helping us fix our headers. Third, it's a lot better to work off of something (that's not that bad to begin with), then to roll your own (availability, time-to-market, duplication of effort, maintenance, to name a few important reasons).
Just for my edification, what would happen to your tree (or what chances would entail) if you just switched to our headers?
--- "Dimitrie O. Paun" dpaun@rogers.com wrote:
Just for my edification, what would happen to your tree (or what chances would entail) if you just switched to our headers?
Our User32/Win32k/GDI32 would break in most interesting ways. ;P
Thats not WINEs fault though. It owes to bad design decisions in ReactOS that must be fixed. When ReactOS was first started there was not much thought in to working with the WINE project (At least not a lot of effort until I joined up) and at the time w32api didnt exist in mingw. If you wanted to do Win32 development you had to use the GNU-Windows SDK package from the FSF. ReactOS did this and has been paying for it now for 5 years......
Thanks Steven
__________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Hello Dimi,
--- "Dimitrie O. Paun" dpaun@rogers.com wrote:
It's a bug in your headers, and it's not present in the Wine headers (one again, why aren't you guys using our headers?)
I am sorry about the confusion and noise on the ReactOS side. I think Its going to come down to just using the WINE headers after all. If we dont get our SDK situtation in ReactOS solved I will make a executive decision and switch all of Win32 in ROS to using your headers and then anything extra we need for DLLs WINE doesnt implement such as MSGINA, etc we can still implement....
Once again I applogize for the noise......we are having growing pains.
We started off with our own DDK/SDK because of the w32api and winelib we not compleate enough for our needs. We dont want to just snapshot Winehq CVS until it is stable enough to suit our needs. The WINE headers are still not always correct so we want to only import a dll after it has been fixed to build with the PSDK. Once every dll and program in Wine CVS can be built with PSDK headers and the Win16 code compiled out I have no problem using WINEs headers but until then we have no way of knowing if everything is correct or not. Also there is still some stuff I want to see if we can somehow do away with in WINE. Can the DECL_WINELIB_TYPE_AW(Blah) stuff ever go away?
Thanks Steven
__________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
-
Dimitrie O. Paun -
Jonathan Wilson -
Steven Edwards -
Vizzini