LPGL functions in Reactos that are stub in Wine
Hello all, I was very interested in comparing the implementation status of reactos and wine. So I coded a little python script to list all the api that are implemented in reactos AND are only stub in wine. Attached to this mail is the list of identified functions. One may note that most of these functions are in the setupapi dll. This is particularly interesting as the setupapi code is LGPL-licenced in Reactos (and was already part of the audit). I tried to port some of these to Wine, but this requires more knowledge than I have. So, is someone interested to port these functions? Best, Julien AssertFail CMP_Init_Detection CMP_Report_LogOn CM_Add_IDA CM_Add_IDA CM_Add_IDW CM_Add_IDW CM_Add_ID_ExA CM_Add_ID_ExA CM_Add_ID_ExW CM_Add_ID_ExW CM_Connect_MachineA CM_Connect_MachineA CM_Create_DevNodeA CM_Create_DevNodeA CM_Create_DevNodeW CM_Create_DevNodeW CM_Create_DevNode_ExA CM_Create_DevNode_ExA CM_Create_DevNode_ExW CM_Create_DevNode_ExW CM_Delete_Class_Key CM_Delete_Class_Key CM_Delete_Class_Key_Ex CM_Delete_Class_Key_Ex CM_Disable_DevNode CM_Disable_DevNode CM_Disable_DevNode_Ex CM_Disable_DevNode_Ex CM_Enable_DevNode CM_Enable_DevNode CM_Enable_DevNode_Ex CM_Enable_DevNode_Ex CM_Enumerate_Classes CM_Enumerate_Classes CM_Enumerate_Classes_Ex CM_Enumerate_Classes_Ex CM_Enumerate_EnumeratorsA CM_Enumerate_EnumeratorsA CM_Enumerate_EnumeratorsW CM_Enumerate_EnumeratorsW CM_Enumerate_Enumerators_ExA CM_Enumerate_Enumerators_ExA CM_Enumerate_Enumerators_ExW CM_Enumerate_Enumerators_ExW CM_Get_Child CM_Get_Child CM_Get_Child_Ex CM_Get_Child_Ex CM_Get_Class_Key_NameA CM_Get_Class_Key_NameA CM_Get_Class_Key_NameW CM_Get_Class_Key_NameW CM_Get_Class_Key_Name_ExA CM_Get_Class_Key_Name_ExA CM_Get_Class_Key_Name_ExW CM_Get_Class_Key_Name_ExW CM_Get_Class_NameA CM_Get_Class_NameA CM_Get_Class_NameW CM_Get_Class_NameW CM_Get_Class_Name_ExA CM_Get_Class_Name_ExA CM_Get_Class_Name_ExW CM_Get_Class_Name_ExW CM_Get_Depth CM_Get_Depth CM_Get_Depth_Ex CM_Get_Depth_Ex CM_Get_DevNode_Registry_PropertyA CM_Get_DevNode_Registry_PropertyA CM_Get_DevNode_Registry_PropertyW CM_Get_DevNode_Registry_PropertyW CM_Get_DevNode_Registry_Property_ExA CM_Get_DevNode_Registry_Property_ExA CM_Get_DevNode_Registry_Property_ExW CM_Get_DevNode_Registry_Property_ExW CM_Get_DevNode_Status CM_Get_DevNode_Status CM_Get_DevNode_Status_Ex CM_Get_DevNode_Status_Ex CM_Get_Device_IDW CM_Get_Device_IDW CM_Get_Device_ID_ExA CM_Get_Device_ID_ExA CM_Get_Device_ID_ExW CM_Get_Device_ID_ExW CM_Get_Device_ID_ListW CM_Get_Device_ID_ListW CM_Get_Device_ID_List_ExA CM_Get_Device_ID_List_ExA CM_Get_Device_ID_List_ExW CM_Get_Device_ID_List_ExW CM_Get_Device_ID_List_SizeA CM_Get_Device_ID_List_SizeA CM_Get_Device_ID_List_SizeW CM_Get_Device_ID_List_SizeW CM_Get_Device_ID_List_Size_ExA CM_Get_Device_ID_List_Size_ExA CM_Get_Device_ID_List_Size_ExW CM_Get_Device_ID_List_Size_ExW CM_Get_Device_ID_Size_Ex CM_Get_Device_ID_Size_Ex CM_Get_Global_State CM_Get_Global_State CM_Get_Global_State_Ex CM_Get_Global_State_Ex CM_Get_Parent CM_Get_Parent CM_Get_Parent_Ex CM_Get_Parent_Ex CM_Get_Sibling CM_Get_Sibling CM_Get_Sibling_Ex CM_Get_Sibling_Ex CM_Get_Version CM_Get_Version CM_Get_Version_Ex CM_Get_Version_Ex CM_Is_Dock_Station_Present CM_Is_Dock_Station_Present CM_Locate_DevNodeA CM_Locate_DevNodeA CM_Locate_DevNodeW CM_Locate_DevNodeW CM_Locate_DevNode_ExA CM_Locate_DevNode_ExA CM_Locate_DevNode_ExW CM_Locate_DevNode_ExW CM_Move_DevNode CM_Move_DevNode CM_Move_DevNode_Ex CM_Move_DevNode_Ex CM_Open_Class_KeyA CM_Open_Class_KeyA CM_Open_Class_KeyW CM_Open_Class_KeyW CM_Open_Class_Key_ExA CM_Open_Class_Key_ExA CM_Open_Class_Key_ExW CM_Open_Class_Key_ExW CM_Reenumerate_DevNode CM_Reenumerate_DevNode CM_Reenumerate_DevNode_Ex CM_Reenumerate_DevNode_Ex CM_Request_Eject_PC CM_Request_Eject_PC CM_Run_Detection CM_Run_Detection CM_Run_Detection_Ex CM_Run_Detection_Ex CM_Set_DevNode_Problem CM_Set_DevNode_Problem CM_Set_DevNode_Problem_Ex CM_Set_DevNode_Problem_Ex CM_Set_DevNode_Registry_PropertyA CM_Set_DevNode_Registry_PropertyA CM_Set_DevNode_Registry_PropertyW CM_Set_DevNode_Registry_PropertyW CM_Set_DevNode_Registry_Property_ExA CM_Set_DevNode_Registry_Property_ExA CM_Set_DevNode_Registry_Property_ExW CM_Set_DevNode_Registry_Property_ExW CM_Setup_DevNode CM_Setup_DevNode CM_Setup_DevNode_Ex CM_Setup_DevNode_Ex CM_Uninstall_DevNode CM_Uninstall_DevNode CM_Uninstall_DevNode_Ex CM_Uninstall_DevNode_Ex CenterWindowRelativeToParent ConcatenatePaths GetSetFileTimestamp GetVersionInfoFromImage MyGetFileTitle RpcBindingCopy RpcSmDestroyClientContext RpcSsDestroyClientContext SetupDiBuildDriverInfoList SetupDiChangeState SetupDiCreateDevRegKeyA SetupDiCreateDevRegKeyW SetupDiDeleteDeviceInfo SetupDiDestroyDriverInfoList SetupDiEnumDriverInfoA SetupDiEnumDriverInfoW SetupDiGetClassDevPropertySheetsA SetupDiGetClassDevPropertySheetsW SetupDiGetDeviceInfoListClass SetupDiGetDeviceInstallParamsW SetupDiGetDeviceInstanceIdA SetupDiGetDeviceInstanceIdW SetupDiGetDeviceRegistryPropertyW SetupDiGetDriverInfoDetailA SetupDiGetDriverInfoDetailW SetupDiGetINFClassA SetupDiGetINFClassW SetupDiGetSelectedDevice SetupDiGetSelectedDriverA SetupDiGetSelectedDriverW SetupDiInstallClassExA SetupDiInstallClassExW SetupDiInstallDevice SetupDiInstallDriverFiles SetupDiLoadClassIcon SetupDiOpenDeviceInfoA SetupDiOpenDeviceInfoW SetupDiRegisterDeviceInfo SetupDiRemoveDevice SetupDiSelectDevice SetupDiSetClassInstallParamsW SetupDiSetDeviceInstallParamsW SetupDiSetDeviceRegistryPropertyA SetupDiSetDeviceRegistryPropertyW SetupDiSetSelectedDevice SetupDiSetSelectedDriverA SetupDiSetSelectedDriverW SetupDiUnremoveDevice SetupGetInfFileListA SetupGetInfFileListW SetupInstallServicesFromInfSectionA SetupInstallServicesFromInfSectionExA SetupInstallServicesFromInfSectionExW SetupInstallServicesFromInfSectionW SetupPromptReboot
Julien wrote:
I was very interested in comparing the implementation status of reactos and wine. So I coded a little python script to list all the api that are implemented in reactos AND are only stub in wine. Attached to this mail is the list of identified functions.
One may note that most of these functions are in the setupapi dll. This is particularly interesting as the setupapi code is LGPL-licenced in Reactos (and was already part of the audit).
Code that originates in ReactOS will generally not be accepted into Wine due to that project's acceptance of developers that participate in "dirty" reverse engineering (ie. translating assembly code to C). Please don't submit code from ReactOS to wine-patches. Mike
On 9/3/06, Mike McCormack <mike(a)codeweavers.com> wrote:
Code that originates in ReactOS will generally not be accepted into Wine due to that project's acceptance of developers that participate in "dirty" reverse engineering (ie. translating assembly code to C).
??
Reverse engineering. Many non-free software packages have a specific clause in their licenses to prohibit reverse engineering. It is the opinion of the ReactOS Project that these license restrictions are only valid to the extent that they prohibit intentional conversion of object code to corresponding source code and subsequently claiming ownership of that source code. Reverse engineering, a form of which happens every time a developer traces into an operating system's core code with a debugger to find a problem with his/her code, is held to be covered by Fair Use. Any source code produced by direct reverse engineering should be treated in exactly the same way as any other non-free source code - useful for study and understanding of the system, but not permitted for inclusion in ReactOS. -- Looks to me like reverse engineered code is "not permitted for inclusion in ReactOS" so how is it there participating in "dirty" reverse engineering?
"Tom Wickline" <twickline(a)gmail.com> wrote:
Looks to me like reverse engineered code is "not permitted for inclusion in ReactOS" so how is it there participating in "dirty" reverse engineering?
That's just a declaration supposed to create a better face on public, nothing more to take it seriously. Same thing about auditing IMO. -- Dmitry.
* On Mon, 4 Sep 2006, Dmitry Timoshkov wrote:
* "Tom Wickline" <twickline(a)gmail.com> wrote:
Looks to me like reverse engineered code is "not permitted for inclusion in ReactOS" so how is it there participating in "dirty" reverse engineering?
That's just a declaration supposed to create a better face on public, nothing more to take it seriously. Same thing about auditing IMO.
Well, Dmitry and Mike, this sound very probable, but have you any proof of "all ReactOS code audit process being fake" ? I very well believe some parts of their code may be dirty, but then please pinpoint this. Otherwise you sound like sentencing ReactOS to death even w/o taking a precise look at it :( IMHO the dirty parts are to be moved or are already moved to the TinyKRNL project, no?
On 9/4/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote:
Well, Dmitry and Mike, this sound very probable, but have you any proof of "all ReactOS code audit process being fake" ?
The audit went awfully quickly, for one thing, and it was done without a neutral third party. Wine's been doing its own audit with the help of the Software Freedom Law Center. If ReactOS worked with those folks, we'd trust the audit results more.
I very well believe some parts of their code may be dirty, but then please pinpoint this. Otherwise you sound like sentencing ReactOS to death even w/o taking a precise look at it :(
I'm afraid it's the other way around at this point - the burden of proof is on ReactOS to show that their code is clean :-(
IMHO the dirty parts are to be moved or are already moved to the TinyKRNL project, no?
I wouldn't know about that. Until ReactOS has been given a clean bill of health by an outside auditor, ReactOS developers are fairly restricted in how they can help Wine; posting bug reports against Wine may be about the best they can do. - Dan
I'm afraid it's the other way around at this point - the burden of proof is on ReactOS to show that their code is clean :-(
A)-no offense, but this sounds like something SCO would say. if you got something (from reactOS current that is already audited..) that you can prove is dirty- please due so. people need facts.
Until ReactOS has been given a clean bill of health by an outside auditor, ReactOS developers are fairly restricted in how they can help Wine; posting bug reports against Wine may be about the best they can do. - Dan
B) i agree with the outside auditor thing. at least before final version comes out. what they're doing is 'fringe' enough that they need to be able to back up the 'cleanness' of their code in a major way. though i do for one believe their internal audit is real- but i agree an outside audit at some time would be much better. C) if wine's offical policy on reactos is to not except contributions from them until a complete audit is done on them by an outside source- that's fine. pretty hardline- but absolutely fine. though- there is a difference between making accusations & having a policy. the first ends up dragging reactos' name through the mud, & -in turn, if they get a clean bill of health will end up dragging wine's name though the mud & will not do anyone any good in the end. the second protects everyone and leaves room for a future. both wine & reactos are great projects & if done correctly will have a huge impact on things in the future. but the direction these conversation seem to be taking doesn't help anyone. i think you just need a policy. (cheerleading all the way... lol) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
* On Mon, 4 Sep 2006, Dan Kegel wrote:
* On 9/4/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote:
have you any proof of "all ReactOS code audit process being fake" ?
The audit went awfully quickly, for one thing, and it was done without a neutral third party. Wine's been doing its own audit with the help of the Software Freedom Law Center. If ReactOS worked with those folks, we'd trust the audit results more.
Well, thanks.
I very well believe some parts of their code may be dirty, but then please pinpoint this. Otherwise you sound like sentencing ReactOS to death even w/o taking a precise look at it :(
I'm afraid it's the other way around at this point - the burden of proof is on ReactOS to show that their code is clean :-(
Now that you have stated Wine already has been through some audit process, this is pretty clear. This is something I wanted to hear, thank you Dan. BTW, can results of Wine's own audit process be seen somewhere on the web? It would be nice to know at least what speed was Wine project audited and when did it happen? How did it influence Wine code size? I seem to be missing this info for some reason :(
On 9/4/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote:
BTW, can results of Wine's own audit process be seen somewhere on the web?
Good question. I don't know the answer, but I'll see if I can find one.
It would be nice to know at least what speed was Wine project audited and when did it happen? How did it influence Wine code size?
Here's a timeline of sorts: in Feb 2005, Wine started thinking about these issues and about contacting the SFLC: http://www.winehq.org/pipermail/wine-devel/2005-February/033437.html By May 2005, Wine was indeed getting involved with the SFLC: http://www.winehq.com/?issue=274#News:%20Software%20Freedom%20Law%20Center In April 2006, there was an announcement about an audit already underway: http://www.winehq.com/?issue=310#Software%20Freedom%20Law%20Center%20Update I doubt the audit is completed yet (these things are asymptotic; you can get to 90% complete a lot faster than 99% complete, etc.). So it's taken Wine something like 16 months so far. Hope that helps. - Dan
Dan Kegel writes:
I doubt the audit is completed yet (these things are asymptotic; you can get to 90% complete a lot faster than 99% complete, etc.).
I am not trying to be a jerk and I am not taking a shot at you personally. I actually think you are a good guy Dan so don't take this the wrong way. To quote you earlier, you said "The audit went awfully quickly, for one thing," referring to the ReactOS audit. The ReactOS audit is 95.3% done currently. The last few percent is going to take a long time because that is where any tainted code, _if_ there is any in the tree, is located. So I would say both audits are going to take the close to the same amount of time. Not only that, but both of them will be carried out in the same time frame where the first ~90% went fast and the last part went slow. But somehow the ReactOS is discredited because it went 'quickly'? I just want to know why you guys are the first ones out the door yelling about how we suck. ReactOS devs for the most part don't have anything bad to say about you guys or your project. But you guys seem to want make us look so bad and it is kinda depressing. Not accepting our patches based on policy is one thing, but just talking trash about us publicly is another thing. I think it would be nice if everyone just left this thread alone for now. You guys made up your minds that you don't want our patches. And thats fine. But there is no reason to continue to express hateful opinions about ReactOS. Brandon
On 9/4/06, Brandon Mark Turner <turnerb7(a)msu.edu> wrote:
I think it would be nice if everyone just left this thread alone for now. You guys made up your minds that you don't want our patches. And thats fine. But there is no reason to continue to express hateful opinions about ReactOS.
I don't hate ReactOS at all. I hope they get their audit completed and verified by a group like the SFLC soon. In the meantime, I hope they can benefit from merging in code from Wine, and I hope they reciprocate by filing bug reports against Wine as they find missing features & apps that need them. - Dan
Sorry Mike but from an external point of view your argument sounds like ideology: 1) I dont understand why someone contributing to ReactOS would have his/her code rejected in all cases. Contributing to ReactOS does not necessary means the code is "dirty" reverse engineering. 2) The author stressed he did not develop this code by any reverse engineering. Now I have two questions: How is it possible to consider rejecting the code without even looking or commenting the patches? Why do you base your argument on ideology and not on facts? What is the point of having another Wine contributor to reimplement the exact same code, rediscover the exact same stuff? The setupapi patches are perhaps incomplete, perhaps the format of the patches are not perfect but rejecting the patches because the author is @reactos.org seems uncorrect. Best, Julien (wannabe wine hacker)
On 9/4/06, Julien <julienc(a)psychologie-fr.org> wrote:
Sorry Mike but from an external point of view your argument sounds like ideology: 1) I dont understand why someone contributing to ReactOS would have his/her code rejected in all cases. Contributing to ReactOS does not necessary means the code is "dirty" reverse engineering.
2) The author stressed he did not develop this code by any reverse engineering.
The thing is, we just don't trust the ReactOS folks at the moment. Perhaps if they can get the SFLC to bless their audit, we could trust them again. The stakes are pretty high; if we include code, and it's later shown to be tainted, the whole project could be endangered. We can get along pretty well without any code from ReactOS, so we probably should. Risking the project for the sake of getting a few functions just doesn't seem worth it. We're very happy to let ReactOS use Wine code, though, there's no problem with that. - Dan
participants (8)
-
Brandon Mark Turner -
Dan Kegel -
Dmitry Timoshkov -
hippy hip -
Julien -
Mike McCormack -
Saulius Krasuckas -
Tom Wickline