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.
Hi Ge
--- Ge van Geldorp gvg@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
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é.
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
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.
--- Alex Ionescu ionucu@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
Steven Edwards wrote:
--- Alex Ionescu ionucu@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
Hi,
--- Alex Ionescu ionucu@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?
- 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
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
Hi,
--- Alex Ionescu ionucu@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 rob@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
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.
Hi,
--- Ge van Geldorp gvg@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@reactos.com:
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@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
-
Alex Ionescu -
Ge van Geldorp -
James Tabor -
magnus＠itkonsult-olsen.com -
Robert Köpferl -
Steven Edwards