RFC: Re: [ros-kernel] Shell32 and dplax
Note: Forwarded to wine-devel I'm more in support of us chaning wine rather then adapting win9x calls to ReactOS. That being said I have enough trouble writing a 3 line patch so my voice doesnt count to much..."You guys are the programmers, I just break shit." IMHO the way WINE handles certain things is really fubar. A good example besides MapSL and ConvertToGlobalHandle is the way WINE implements PSAPI. All wine psapi does it convert the toolhelp functions already implemented in to the needed format with a wineserver call or two thrown in. If we are going to use wine and not fork the crap out of it then we should fix the 9xisms as we find them. Currently wine has all sorts of ways for doing things, you have win16 apis being called in some places, ntdll in others and then 9xisms all over the place. So far we have MapSL ConvertToGlobalHandle PSAPI DriectX HAL interfaces ? idunno I guess it comes to what can we do to better share code. Currently there is not a chance in hell of us sharing PSAPI in its current state. I started two bugs in wines bugzilla a few weeks ago regarding it. Mabey we should have a meta-bug for making WINE more NT like in "certain" areas. I dont expect the wine projects to make all sorts of changes just for us and not as they are trying to get a 1.0 release. Anyone got any feedback? Mabey we will get more support for this once David and Jason are done with the basic Windowing. Steven
MapSL is in wine kernel32 also, Oh yeah, it's part of windows 9x kernel32.dll too. James
__________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
IMHO the way WINE handles certain things is really fubar. basically, since Wine evolves like Windows did (16 bit => win32 à la Win9x => NT infra), wine suffers from the same defaults :-(
however, I agree with you that spreading wineserver calls all over the DLLs is a bad idea IMO, the ultimate design would be to only have wineserver calls in NTDLL, but that's a long way to go... it would permit nice things as: - portability on windows for testing the various DLLs - (should be good for ReactOS) - would allow to resign drop in replacement for NTDLL, like moving (part of) wineserver inside the Linux kernel - ... to start with, I think keeping the wineserver calls only in the holy three DLLs should be an acceptable short term target BTW, I did extend a bit the PSAPI implementation (for some missing API) and was also upset by the calls to toolhelp for that in short, moving to NT architecture is the way to go, but it'll need some time may be we could also create a metabug on bugzilla for this and link all known issues to this meta-bug. A+
in short, moving to NT architecture is the way to go, but it'll need some time may be we could also create a metabug on bugzilla for this and link all known issues to this meta-bug.
I will start a meta bug for this and being to track these issues as I find them. With any luck we will be able to help with these issues in the next few months. Steven __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Small steps are best - they usually lead to things getting done in the end. A more NT-architecture-friendly WINE would really help us guys working on ReactOS! - Jason --- Eric Pouech <eric.pouech(a)wanadoo.fr> wrote:
IMHO the way WINE handles certain things is really fubar. basically, since Wine evolves like Windows did (16 bit => win32 � la Win9x => NT infra), wine suffers from the same defaults :-(
however, I agree with you that spreading wineserver calls all over the DLLs is a bad idea IMO, the ultimate design would be to only have wineserver calls in NTDLL, but that's a long way to go... it would permit nice things as: - portability on windows for testing the various DLLs - (should be good for ReactOS) - would allow to resign drop in replacement for NTDLL, like moving (part of) wineserver inside the Linux kernel - ...
to start with, I think keeping the wineserver calls only in the holy three DLLs should be an acceptable short term target
BTW, I did extend a bit the PSAPI implementation (for some missing API) and was also upset by the calls to toolhelp for that
in short, moving to NT architecture is the way to go, but it'll need some time may be we could also create a metabug on bugzilla for this and link all known issues to this meta-bug.
A+
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf _______________________________________________ reactos-kernel mailing list reactos-kernel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/reactos-kernel
__________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
At 08.15 09/07/2002, you wrote:
MapSL ConvertToGlobalHandle
what are these two for? I've never heard them
PSAPI
I'm (was) working on PSAPI, but it's obviously based on the NT API. The module enumeration (not done yet - I have to dig down the LDR structures) will require a memory layout that matches NT's down to the byte - specifically, all processes must have a PEB, and it must be exactly identical to NT's. I think the Wine guys should better keep their toolhelp-based implementation. It's an especially "delicate" area
participants (4)
-
Eric Pouech -
Jason Filby -
KJK::Hyperion -
Steven Edwards