End-of-merge for some components shared with Wine

[Ge van Geldorp]

It's becoming impossible for me to keep some components synced with Wine.
For some components, we have too many changes in our tree which were not
submitted to Wine. I've tried to submit some of "our" changes, but was
unable to answer questions asked by the Wine people, since I simply do not
have enough knowledge of those particular DLLs. The original (ReactOS)
authors of the changes are not interested or currently unable to answer
either.

So, the following components are now effectively forked:
- tools/widl
- lib/dinput
- lib/setupapi
- lib/winmm

Gé van Geldorp.

[Steven Edwards]

Hi Ge

--- Ge van Geldorp <gvg(a)reactos.com> wrote:
>   It's becoming impossible for me to keep some
> components synced with Wine.
>  For some components, we have too many changes in our tree which were not
>  submitted to Wine. I've tried to submit some of "our" changes, but was
>  unable to answer questions asked by the Wine people, since I simply do not
>  have enough knowledge of those particular DLLs. The original (ReactOS)
>  authors of the changes are not interested or currently unable to answer
>  either.
>  
>  So, the following components are now effectively forked:
>  - tools/widl 
Eric has said he would merge this at some point.

>   - lib/dinput 
There were some changes that needed to go on in the winehq side last time a checked, for a
Xorg
extension to handle the mouse that BBrox and others were working on. We can resync this
later.

>   - lib/setupapi 
I will keep working on this. The issue we have is that Alexandre does not want to accept
certain
patches unless we can prove a real world application depends on certain behavior.
Private/Undocumented APIs won't be synced.

>   - lib/winmm 
Is the diff for winmm really that large?

Thanks
Steven


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Ge van Geldorp]

>   From: Steven Edwards
>  
>  Is the diff for winmm really that large? 
No, the issue here is that Wine-20050725 now uses exception handling in this
DLL. I got a lot of compile errors on this. After spending a lot of time on
some of the other components (lots of DLLs had their EOL type changed,
meaning svn thought each and every line was changed in the ReactOS tree and
gave conflicts on all merges for those DLLs) I got fed up and gave up on it.
After I sleep a few nights I might give it another try.
I am not going to work on the other ones anymore. If the authors can't be
bothered to help get their changes in Wine I can't be bothered to spend time
on it either.

Gé.

[Alex Ionescu]

Ge van Geldorp wrote:

>  
> I am not going to work on the other ones anymore. If the authors can't be
> bothered to help get their changes in Wine
>  
I wouldn't blame the authors for WINE's ultra-conservative app-based 
developement strategy. I woudln't blame WINE either; that's been their 
development process for years and since they seem to be sucesful (for 
now), it would be fair to say that their strategy is working. Whether it 
pays off or not, is too premature to say.

>   I can't be bothered to spend time
> on it either.
>   
>  
I agree. Our implementation of setupapi is clearly more advanced and 
cleaner then WINE's. They are the ones on the losing side, unless they 
choose to somehow accomodate us. I've never liked the policy of "if you 
want WINE changes, we spend time and make ROS accept them. If WINE wants 
ROS changes, we spend time and make WINE accept them". It seems 
counterproductive. WINE should get a guy to sync ROS changes as well, 
and have a process to make sure they get accepted. It seems silly to 
require a real-world application. Of COURSE there is one...or else why 
would the API be exported? Sure, there might be only three applications 
in the world, but it doesn't mean they don't exist. And finding 3 
applications out of the billions that exist is worse then finding a 
needle in a hay stack. If you don't care about three apps, then you run 
into a dangerous slippery slope. Who decides the number of apps you're 
willing to sacrifice? 3? 30? 300? If you start sacrificing apps here and 
there, the number grows exponentially.

>  Gé.
>   
>  
Best Regards,
Alex Ionescu

[James Tabor]

Hi!

Ge van Geldorp wrote:
>   It's becoming impossible for me to keep some
> components synced with Wine.
>  For some components, we have too many changes in our tree which were not
>  submitted to Wine. I've tried to submit some of "our" changes, but was
>  unable to answer questions asked by the Wine people, since I simply do not
>  have enough knowledge of those particular DLLs. The original (ReactOS)
>  authors of the changes are not interested or currently unable to answer
>  either.
>   
HOOOO! I'm trying REAL HARD MAINTAINING CONTROL OF MY COMMENTS!!!!!
OH! It hurt to be nice right now! AAAHHHH!

>   So, the following components are now effectively
> forked:
>  - tools/widl 
I'm at a loss, this was a ROS and Wine project, how did this run away from us?

>   - lib/dinput 
Don't know about this one.

>   - lib/setupapi 
same here.

>   - lib/winmm 
It never been synced.

Alex Ionescu wrote:
>   Ge van Geldorp wrote:
>  
> >  
> >  I am not going to work on the other ones anymore. If the authors can't be
> >  bothered to help get their changes in Wine
> >  
>  I wouldn't blame the authors for WINE's ultra-conservative app-based 
>  developement strategy. I woudln't blame WINE either; that's been their 
>  development process for years and since they seem to be sucesful (for 
>  now), it would be fair to say that their strategy is working. Whether it 
>  pays off or not, is too premature to say.
>   
Yelling and screaming!

> >   I can't be
> > bothered to spend time
> >  on it either.
> >   
> >  
>  I agree. Our implementation of setupapi is clearly more advanced and 
>  cleaner then WINE's. They are the ones on the losing side, unless they 
>  choose to somehow accomodate us. I've never liked the policy of "if you 
>  want WINE changes, we spend time and make ROS accept them. If WINE wants 
>  ROS changes, we spend time and make WINE accept them". It seems  
More yelling and screaming!

>   counterproductive. WINE should get a guy to sync ROS
> changes as well, 
>  and have a process to make sure they get accepted. It seems silly to 
>  require a real-world application. Of COURSE there is one...or else why 
>  would the API be exported? Sure, there might be only three applications 
>  in the world, but it doesn't mean they don't exist. And finding 3 
>  applications out of the billions that exist is worse then finding a 
>  needle in a hay stack. If you don't care about three apps, then you run 
>  into a dangerous slippery slope. Who decides the number of apps you're 
>  willing to sacrifice? 3? 30? 300? If you start sacrificing apps here and 
>  there, the number grows exponentially.
>   
We have to maintain backward compatibility, btw.

> >   Gé.
> >   
> >  
>  Best Regards,
>  Alex Ionescu
>   
8^\, I feel your frustration,
James


PS. My yelling comments are not pointed @ any Ros developers.

[Steven Edwards]

--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   require a real-world application. Of COURSE there is
> one...or else why 
>  would the API be exported? Sure, there might be only three applications  
A real world application that is not part of Windows. If you can find a real world
application
that is not part of Windows or made by Microsoft and NOT called a OS COMPONATE and makes
use of
advapi32.SystemFunction* or setupapi.stringtable* then I will agree.

Thanks
Steven


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Alex Ionescu]

Steven Edwards wrote:

>  --- Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   
>
> >  require a real-world application. Of COURSE there
> > is one...or else why 
> > would the API be exported? Sure, there might be only three applications 
> >     
> >  
> A real world application that is not part of Windows. If you can find a real world
> application
> that is not part of Windows or made by Microsoft and NOT called a OS COMPONATE and makes
> use of
> advapi32.SystemFunction* or setupapi.stringtable* then I will agree.
>   
>  
Flawed reasoning. Here are some reasons:

Even if only an Windows DLL uses the function, it implies that the 
Windows DLL needs that functionality. It's also highly likely that DLL 
has exported functions used by applications, implying in turn that WINE 
has a FOSS version of that DLL. Now, it's not a far stretch that if this 
DLL needs to import an undocumented API from another DLL, it actually 
*needs* that functionality, and so will WINE. So let's say that 
crypt32.dll needs advapi32!SystemFunctionImSuperUndocumented007 to 
generate an RC5 hash, then WINE also probably needs a way to get an RC5 
hash. What are the solutions?

1) Implement a home-made RC5 hash and call it CryptpRc5Hash, and stick 
it as an internal static function inside crypt32.dll
2) Above, but stuck into a winelib.dll
3) Above, but stuck into advapi32!SystemFunctionImSuperUndocumented007, 
with minor changes to make sure it corresponds to the same parameters.

What harm does #3 do? It gives the same result as #1/2, but has the 
added avantage that if, somehow, somewhere, an external app needs an RC5 
hash and figured out that function, it will work. This goes back to what 
I said, undocumented functions are not exported just for the fun of it. 
Even if they are only used by other DLLs, those DLLs need that 
functionality and so will the WINE dlls.

It's not like WINE developers were forced or had to spend time to write 
these functions, one of our developers did (and he submited patches to 
WINE). What possible -harm- can it do?

By the way, IE and WMP are OS Components. According to what you said, 
these also don't count:
"made by Microsoft and NOT called a OS COMPONATE".

I certaintly hope they don't start using undocumented functions! (But 
trust me, their calls do end up in those SystemFunctionXXX advapi calls 
through other DLLs). Almost any crypto/security call does.

>  Thanks
> Steven
>
>
>   
>  
Best Regards,
Alex Ionescu

[Steven Edwards]

Hi,

--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   Even if only an Windows DLL uses the function, it
> implies that the 
>  Windows DLL needs that functionality. It's also highly likely that DLL 
>  has exported functions used by applications, implying in turn that WINE 
>  has a FOSS version of that DLL. Now, it's not a far stretch that if this 
>  DLL needs to import an undocumented API from another DLL, it actually 
>  *needs* that functionality, and so will WINE. So let's say that 
>  crypt32.dll needs advapi32!SystemFunctionImSuperUndocumented007 to 
>  generate an RC5 hash, then WINE also probably needs a way to get an RC5 
>  hash. What are the solutions?
>  
>  1) Implement a home-made RC5 hash and call it CryptpRc5Hash, and stick 
>  it as an internal static function inside crypt32.dll
>  2) Above, but stuck into a winelib.dll
>  3) Above, but stuck into advapi32!SystemFunctionImSuperUndocumented007, 
>  with minor changes to make sure it corresponds to the same parameters.
>  
>  What harm does #3 do? It gives the same result as #1/2, but has the 
>  added avantage that if, somehow, somewhere, an external app needs an RC5 
>  hash and figured out that function, it will work. This goes back to what 
>  I said, undocumented functions are not exported just for the fun of it. 
>  Even if they are only used by other DLLs, those DLLs need that 
>  functionality and so will the WINE dlls. 
If its a Windows System Dll then running it on Wine gains you nothing except people being
lazy and
not coding a proper replacement. Using this logic Wine should implement 8 layers of
abstraction

Linux Kernel Crypto APIs->Ksecdd.sys->emulated syscall
magic->advapi32.systemfunction->crypt.dll->rsabase.dll->???

If I am a Linux developer trying to make a API replacement as a migration tool I am going
to make
the crypt.dll and rsabase.dll be a wraper for a exported kernel API or use openssl,
tinyssl or
whatever else and save my time. Why? Because I want to have all Linux native applications.
I could
give 2 shits about following the precious Windows design for everything because ultimatly
my end
goal it to have native Linux applications not some bloated compatiblity layer.

It is a totally different mindset and if we want to share some code we have to work around
that.
Some things might not be shared. Big deal.

>   It's not like WINE developers were forced or had
> to spend time to write 
>  these functions, one of our developers did (and he submited patches to 
>  WINE). What possible -harm- can it do? 
No thats the point. Our developers ARE NOT SENDING PATCHES TO WINE AS A GENERAL RULE. They
are
making massive changes and then doing a drop of code. That is not a patch. Then its
impossible to
merge in fixes from Winehq and keep our stuff up2date. Lets say I implement dllname.foo
and wine
has dllname.bar then I go and implement dllname.foobar1 dllname.foobar2 dllname.foobar3
dllname.foobar4 all of which depend on dllname.foo and later someone else in Wine then
goes and
fixes a bug in dllname.foo. Guess what we cannot sync the patch because it might break X
number of
other functions.
 
>   By the way, IE and WMP are OS Components. According to
> what you said, 
>  these also don't count:
>  "made by Microsoft and NOT called a OS COMPONATE".
>  
>  I certaintly hope they don't start using undocumented functions! (But 
>  trust me, their calls do end up in those SystemFunctionXXX advapi calls 
>  through other DLLs). Almost any crypto/security call does. 
Right. Show me a real world application that calls all of the advapi32.systemfunction apis
and I
might agree with you. I know of one that does in totally violation of all of the rules and
breaks
on version of Windows to another. Ditto for the undocumented Setupapi functions which by
the way
Change from one version of Windows to another. Compare Windows 2000 setupapi.stringtable*
to
Windows XP/2K3 setupapi.pstringtable functions. They are exported under a totally
different name
and to date I have only found 1 application that uses them and yes it is a OS COMPONATE as
defined
by the EULA.

Thanks
Steven



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

[Alex Ionescu]

Steven Edwards wrote:

>  Hi,
>   
>
>
>
> If its a Windows System Dll then running it on Wine gains you nothing except people being
> lazy and
> not coding a proper replacement. Using this logic Wine should implement 8 layers of
> abstraction
>
> Linux Kernel Crypto APIs->Ksecdd.sys->emulated syscall
> magic->advapi32.systemfunction->crypt.dll->rsabase.dll->???
>   
>  
The best solution would be to follow that, yes, but I concede that it is 
not in WINE's best interests. Nevertheless, they will eventually suffer 
from not doing it that way. Look at how much stuff had to be done for 
apps like Safedisc, which required WINE to implement a completely 
emulated kernel-mode driver layer.

>  If I am a Linux developer trying to make a API
> replacement as a migration tool I am going to make
> the crypt.dll and rsabase.dll be a wraper for a exported kernel API or use openssl,
> tinyssl or
> whatever else and save my time. Why? Because I want to have all Linux native applications.
> I could
> give 2 shits about following the precious Windows design for everything because ultimatly
> my end
> goal it to have native Linux applications not some bloated compatiblity layer.
>   
>  
Ok, so you're saying that crypt.dll should directly call some linux 
native openssl library... that makes sense. Now, what if 5 other 
exported, publically used dlls also need to call SystemFunction007? They 
will also have to call some linux native openssl library. Now, if that 
library is included statically, you've bloated 5 DLLs. If it's simply an 
external lib, then how much harder is it to stub SystemFunction007 to 
call the openssl library? That is 10 lines of adtionnal code, with the 
added benefit that if anyone ever calls that undocumented export, you 
can handle it. But in reality, even that would be flawed, because I do 
agree that ksecdd.sys should actually be called if  needed. Now you're 
going to call me crazy and say that's even beyond undocumented, plus 
it's kernel mode. Go ahead and laugh... I happen to have a copy of the 
WDK, and you'd be "pleased" to know that the KSECDD APIs are becoming 
documented. What if some of ksecdd are just regular IOCTLs that a 
user-mode app like safedisc would launch? You'd probably hack ksecdd to 
use openssl as well... but now you're having a duplicated design, where 
crypt is using openssl, advapi006 is not implemented, and ksecdd is also 
using openssl. Nice waste! If it would've been done properly since the 
start, you assure full compatibility. What happens when MS documents the 
SystemFunctionsXXX, like they've done with GdiEntryXXX? You scramble to 
implement the functions and tell yourself "Shit, I should've accepted 
that patch last year!"

>  It is a totally different mindset and if we want to
> share some code we have to work around that.
> Some things might not be shared. Big deal.
>
>   
>
> >  It's not like WINE developers were forced or
> > had to spend time to write 
> > these functions, one of our developers did (and he submited patches to 
> > WINE). What possible -harm- can it do?
> >     
> >  
> No thats the point. Our developers ARE NOT SENDING PATCHES TO WINE AS A GENERAL RULE. 
>  
Well that's a big problem then, and we should have a serious discussion 
with those developers, as well as ensure that we don't allow commits to 
WINE libs if we don't see a patch first.

>  Right. Show me a real world application that calls all
> of the advapi32.systemfunction apis and I
> might agree with you. I know of one that does in totally violation of all of the rules and
> breaks
> on version of Windows to another. Ditto for the undocumented Setupapi functions which by
> the way
> Change from one version of Windows to another. Compare Windows 2000 setupapi.stringtable*
> to
> Windows XP/2K3 setupapi.pstringtable functions. They are exported under a totally
> different name
> and to date I have only found 1 application that uses them and yes it is a OS COMPONATE as
> defined
> by the EULA.
>   
>  
I concede on that extremly weird and unused API, but you're using that 
case as a justification not to implement *ANY* unimplemented APIs, 
aren't you?
NtDeleteFile is undocumented too... should we forget about it? My 
apologies if you were only referring to setupapi.

>  Thanks
> Steven
>
>
>
> 		
>   
>  
Best regards,
Alex Ionescu

[Steven Edwards]

Hi,

--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   The best solution would be to follow that, yes, but I
> concede that it is 
>  not in WINE's best interests. Nevertheless, they will eventually suffer 
>  from not doing it that way. Look at how much stuff had to be done for 
>  apps like Safedisc, which required WINE to implement a completely 
>  emulated kernel-mode driver layer. 
They would have had to be done anyway and it would have taken just as long and in the
interm
hardly applications would work on Wine just like ReactOS can really not run much of
anything. Wine
is a userspace server. They could properly implement a kernel compatiblity layer for
loading
Windows drivers but even still there are all sorts of issues you are not taking in to
account.
Linux's lack of a stable driver interface, the SCSI subsystem changing from one Linux
kernel
Revision to another making emulation of Windows ICTOLs a pain and constanly changing.

>   Ok, so you're saying that crypt.dll should
> directly call some linux 
>  native openssl library... that makes sense. Now, what if 5 other 
>  exported, publically used dlls also need to call SystemFunction007? They 
>  will also have to call some linux native openssl library. Now, if that 
>  library is included statically, you've bloated 5 DLLs. If it's simply an 
>  external lib, then how much harder is it to stub SystemFunction007 to 
>  call the openssl library? That is 10 lines of adtionnal code, with the 
>  added benefit that if anyone ever calls that undocumented export, you 
>  can handle it. But in reality, even that would be flawed, because I do 
>  agree that ksecdd.sys should actually be called if  needed. Now you're 
>  going to call me crazy and say that's even beyond undocumented, plus 
>  it's kernel mode. Go ahead and laugh... I happen to have a copy of the 
>  WDK, and you'd be "pleased" to know that the KSECDD APIs are becoming 
>  documented. What if some of ksecdd are just regular IOCTLs that a 
>  user-mode app like safedisc would launch? You'd probably hack ksecdd to 
>  use openssl as well... but now you're having a duplicated design, where 
>  crypt is using openssl, advapi006 is not implemented, and ksecdd is also 
>  using openssl. Nice waste! If it would've been done properly since the 
>  start, you assure full compatibility. What happens when MS documents the 
>  SystemFunctionsXXX, like they've done with GdiEntryXXX? You scramble to 
>  implement the functions and tell yourself "Shit, I should've accepted 
>  that patch last year!" 
And in the mean time X number of Application would have been working attracting more users
to the
project as well as more money and more developers. As opposed to saying "We are going
to do a 100%
perfect replication with no working around the design limiations along the way".
Using the no
creative solutions method is boring, It gets nothing working short term, It gives
Microsoft more
time to lock the world in to the next version of the legal crack known as windows. By the
time we
are even 90% compatible with NT4, Windows Server 2010 is going to be out following these
design
decisions.

>   Well that's a big problem then, and we should have
> a serious discussion 
>  with those developers, as well as ensure that we don't allow commits to 
>  WINE libs if we don't see a patch first. 
>   I concede on that extremly weird and unused API, but
> you're using that 
>  case as a justification not to implement *ANY* unimplemented APIs, 
>  aren't you? 
No I am using that as a example of clean room reverse enginering. Find me a application
that uses
it so I can replicate the interface in a clean room without Windows, or a prototype
documented in
a published header and I will have a legal leg to stand on. Even when the Wine guys have
used
tools like IDA, etc they have not been reversing Windows. They have been looking at the
applications that use Windows and seeing what that application expects. I don't run
Windows nor I
am going to potentially break the law in working on ReactOS and taint the project by
dissasmbling
a running Windows system. 100% driver and application compatiblity can be reached without
it.

>   NtDeleteFile is undocumented too... should we forget
> about it? My 
>  apologies if you were only referring to setupapi. 
NtDeleteFile might not be a good example but lets take a user32->Win32k.sys functions.
We have two
options. 1 Implementing everything properly and it taking years/decade/never or 2. Taking
shortcuts using more Wine code and maybe violating some design rules short term. I will
give you a
example that might work. Right now our code for GetSystemMetrics is mostly a hard coded
stub in
User32->Win32k I could spend a month rewriting it in Win32k.sys and get a 20% working
implementation or I could take Wines 2000 line source file and stick it in user32.dll. Now
there
are other functions in Win32k.sys that depend on NtUserGetSystemMetrics(CX_*) so I would
still
leave the old code in Win32k.sys there and slowly start improving it so that I could being
to
forward options from User32.GetSystemMetrics to win32k.NtUserGetSystemMetrics one at a
time.

Using your logic you are saying "You are not going to implement
NtUserGetSystemMetrics!!!" No I am
saying I am going to use what code we can to get applications working today while
designing it
where it can be properly implemented long term. 

Thanks
Steven



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

[Robert Köpferl]

Just onece for my knowledge:
what is this omnous setupapi?

[Steven Edwards]

--- Robert Köpferl <rob(a)koepferl.de> wrote:
>   Just onece for my knowledge:
>  what is this omnous setupapi? 
Its a library that handles a good chunk of the undocument magic of parsing *.inf scripts
from
vendor drivers, talking to the PnP manager and making Windows applications think they have
working
plug and play.

It also does quite a bit of other undocumented stuff.....

Thanks
Steven



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

[Ge van Geldorp]

>   From: Steven Edwards
>
>  - tools/widl
>  Eric has said he would merge this at some point. 
And I'll be happy to include it again in the monthly merges when this has
been done.

>   From: Alex Ionescu
>
>  I've never liked the policy of "if you want WINE changes, we 
>  spend time and make ROS accept them. If WINE wants ROS 
>  changes, we spend time and make WINE accept them". 
For the WIDL work, Mike McCormack (one of the Wine guys) did step up and
offer help. However, when we're unable to answer questions like:

>   For example, why are SHORT and USHORT treated as equal
> in 
tools/widl/client.c?
>  
>  +                case RPC_FC_USHORT:
>  +                case RPC_FC_SHORT:
>  +                    print_client("0x4e,    /* FC_IN_PARAM_BASETYPE
*/\n");
>   +                    print_client("0x%02x,    /*
> FC_USHORT */\n", 
>  RPC_FC_SHORT);
>  +                    break;
>  +                case RPC_FC_ULONG:
>  +                case RPC_FC_LONG:
>  +                    print_client("0x4e,    /* FC_IN_PARAM_BASETYPE
*/\n");
>   +                    print_client("0x%02x,    /*
> FC_LONG */\n", 
>  RPC_FC_LONG);
>  +                    break; 
the patch is not going to be accepted. Now, I have no idea what the above
code fragment is supposed to do, but my experience is that when technical
issues are raised about patches they are usually right.

>   From: James Tabor
>
>  - lib/winmm
>  It never been synced. 
Bzzzt, wrong answer. Check svn log.

Gé van Geldorp.

[Steven Edwards]

Hi,

--- Ge van Geldorp <gvg(a)reactos.com> wrote:
>   I am not going to work on the other ones anymore. If
> the authors can't be
>  bothered to help get their changes in Wine I can't be bothered to spend time
>  on it either. 
I understand. There are some things that are worth the effort of trying to sync on every
Wine
release anyway. Thanks for the time you spend on this btw...I know it can be boring.

As for other developers view of the Wine project and its policies, I am only going to say
this one
more time. NOTHING stops anyone from sending patches to Wine. If you don't like the
Winehq rules
you are even free to fork it according to the license but to just not send patches and
then lay
blame at them because its hard to get patches in to wine.....Well if you don't even
send patches
in, of course they are not just just going to magicly go in CVS. We have rules in our
project
about large patches and branches and they have thiers. I NEVER see Wine developers coming
in here
bitching about our Version Control policies.

Thanks
Steven



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

dinput patch must be rewriten, for we have only done a hack to find mouse and
keyboard. and some other hack to getting some apps and games works. and do not
crach in windows. Last time I did try wine with our patch the dinput was
unstable in windows and reactos. and I did rewrite the dinput patch.


Quoting Ge van Geldorp <gvg(a)reactos.com>om>:

>   It's becoming impossible for me to keep some
> components synced with Wine.
>  For some components, we have too many changes in our tree which were not
>  submitted to Wine. I've tried to submit some of "our" changes, but was
>  unable to answer questions asked by the Wine people, since I simply do not
>  have enough knowledge of those particular DLLs. The original (ReactOS)
>  authors of the changes are not interested or currently unable to answer
>  either.
>
>  So, the following components are now effectively forked:
>  - tools/widl
>  - lib/dinput
>  - lib/setupapi
>  - lib/winmm
>
>  Gé van Geldorp.
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>