Hi,
I'm leaving the ReactOS project. The goals of some developers don't match my goals.
Bye bye Hartmut
What sparked this?
On 1/17/06, Hartmut Birr osexpert@googlemail.com wrote:
Hi,
I'm leaving the ReactOS project. The goals of some developers don't match my goals.
Bye bye Hartmut _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- "I had a handle on life, but then it broke"
TwoTailedFox wrote:
What sparked this?
Sometimes in the past, I didn't understand some changes, because the code didn't make sense for the current state of reactos and was not used. Currently, I've compared disassembled code from win2k and winxp with ReactOS. In my opinion, some of the developers do disassemble windows code to implement ReactOS.
- Hartmut
Hi,
On 1/17/06, Hartmut Birr osexpert@googlemail.com wrote:
Sometimes in the past, I didn't understand some changes, because the code didn't make sense for the current state of reactos and was not used. Currently, I've compared disassembled code from win2k and winxp with ReactOS. In my opinion, some of the developers do disassemble windows code to implement ReactOS.
Can you list offending code with a list of svn commits?
Thanks
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Hi all
According to our project's legal policy document, reverse-engineering is allowed to study the internals of Windows, but cannot be used as the basis to write code for particular functions.
What we haven't defined is the process of what happens when someone suspects that our policy has been violated. I think now is a good time to do that. I also don't think the offender - even if proven guilty - should be kicked out of the project (at least not for a 1st time violation). The code, however, should be removed and rewritten.
If we don't act on this then the problem will only fester and may be the end of the project one day.
Hartmut: I think you need to come forward with your investigations results as Steven asked. Whether or not you come back (I hope you do), we can't ignore this.
Cheers Jason
On 1/18/06, Steven Edwards winehacker@gmail.com wrote:
Can you list offending code with a list of svn commits?
Thanks
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
From: Jason Filby
What we haven't defined is the process of what happens when someone suspects that our policy has been violated. I think now is a good time to do that. I also don't think the offender - even if proven guilty - should be kicked out of the project (at least not for a 1st time violation). The code, however, should be removed and rewritten.
I'm sorry, but I disagree with you on this. We have a clear policy, everyone contributing to the project should feel bound by it. Copyright violation is a serious matter for software in general, but for this project in particular. I think everyone has the same experience: when you tell other people about ReactOS one of the first questions usually is: but won't Microsoft sue you? My standard reply is: how could they, we're not doing anything illegal. I think we better make damn sure that we are indeed not doing anything illegal.
Why should we give someone who endangers the whole project only a slap on the wrist? When he knowingly violates the policy (not to mention the law), how can I trust him not to do that again? Trust is an important part of this project, I'm not in the habit of disassembling Microsoft Windows to check if a particular contribution was ripped from Windows, I need to be able to trust my fellow devs. If it is proven beyond a reasonable doubt that someone violated that trust I want his commit rights to be terminated, immediately. After that we need to assess what damage was done and how we can repair it.
Hartmut: I think you need to come forward with your investigations results as Steven asked.
Yes, please. If you know there's something broken in this project, please give us the chance to fix it.
GvG
Jason Filby wrote:
Hi all
According to our project's legal policy document, reverse-engineering is allowed to study the internals of Windows, but cannot be used as the basis to write code for particular functions.
Hi,
I don't agree completely with our legal policy. In my opinion, it is allowed to use reverse-engineering to find out interfaces or something like this. It isn't allowed to disassemble windows to study how the fast call entry works or to find out how the APC code is implemented. There exist some paper on the web. It is allowed to use the nice paper from David P. Probert (Windows Kernel Development). It isn't allowed to use the code from the dude called CrazyLord (Reverse Engineer).
- Hartmut
Hartmut Birr wrote:
Hi,
I don't agree completely with our legal policy. In my opinion, it is allowed to use reverse-engineering to find out interfaces or something like this. It isn't allowed to disassemble windows to study how the fast call entry works or to find out how the APC code is implemented. There exist some paper on the web. It is allowed to use the nice paper from David P. Probert (Windows Kernel Development). It isn't allowed to use the code from the dude called CrazyLord (Reverse Engineer).
This isn't quite fair, unfortunately. We've gone a long time without an explicit policy regarding this subject, mostly because we were all in agreement. You can't boot someone out because they violated a rule that wasn't made clear to them. OTOH, if our position is clearly stated and is violated then I agree - begone with them.
Royce Mitchell III wrote:
Hartmut Birr wrote:
Hi,
I don't agree completely with our legal policy. In my opinion, it is allowed to use reverse-engineering to find out interfaces or something like this. It isn't allowed to disassemble windows to study how the fast call entry works or to find out how the APC code is implemented. There exist some paper on the web. It is allowed to use the nice paper from David P. Probert (Windows Kernel Development). It isn't allowed to use the code from the dude called CrazyLord (Reverse Engineer).
This isn't quite fair, unfortunately. We've gone a long time without an explicit policy regarding this subject, mostly because we were all in agreement. You can't boot someone out because they violated a rule that wasn't made clear to them. OTOH, if our position is clearly stated and is violated then I agree - begone with them.
Looking on http://www.reactos.org/xhtml/en/dev_legalreview.htm http://www.reactos.org/xhtml/en/dev_legalreview.html, I found: <snip> C. Copyrights of Others The ReactOS Project depends on copyright law for the protection of its code, and by the same token, it respects the copyrights of others. Following are the policies of the ReactOS Project as they relate to copyright: <snip> Disassembly of object code is held to be a form of reverse engineering. Disassembled code listings should be treated with the same terms of license as the object code itself. <snip>
If I understand this correctly with my poor English, it isn't possible to disassembly a part of windows and uses this information to implement the same code in ReactOS.
- Hartmut
You MAY use the INFORMATION to implement the same functionality in ReactOS. You MAY NOT copy (and I'm talking about copy/pasting here) the work/implementation. This can be hard to do since one may think, why would I want to spend hours thinking up a new implementation when I've got a perfectly good one right in front of me? So to avoid this pitfall it is best to describe the functionality in plain English and let another developer implement the functionality using only the English text. A lot of work, but this is exactly why we have copyright. Microsoft did spend even more effort on the original implementation.
Casper
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Hartmut Birr Sent: 18. januar 2006 22:45 To: ReactOS Development List Subject: Re: [ros-dev] Bye bye
Royce Mitchell III wrote:
Hartmut Birr wrote:
Hi,
I don't agree completely with our legal policy. In my opinion, it is allowed to use reverse-engineering to find out interfaces or something like this. It isn't allowed to disassemble windows to study how the fast call entry works or to find out how the APC code is implemented. There exist some paper on the web. It is allowed to use the nice paper from David P. Probert (Windows Kernel Development). It isn't allowed to use the code from the dude called CrazyLord (Reverse Engineer).
This isn't quite fair, unfortunately. We've gone a long time without an explicit policy regarding this subject, mostly because we were all in agreement. You can't boot someone out because they violated a rule that wasn't made clear to them. OTOH, if our position is clearly stated and is violated then I agree - begone with them.
Looking on http://www.reactos.org/xhtml/en/dev_legalreview.htm http://www.reactos.org/xhtml/en/dev_legalreview.html, I found: <snip> C. Copyrights of Others The ReactOS Project depends on copyright law for the protection of its code, and by the same token, it respects the copyrights of others. Following are the policies of the ReactOS Project as they relate to copyright: <snip> Disassembly of object code is held to be a form of reverse engineering. Disassembled code listings should be treated with the same terms of license as the object code itself. <snip>
If I understand this correctly with my poor English, it isn't possible to disassembly a part of windows and uses this information to implement the same code in ReactOS.
- Hartmut
Forgot my reference:
http://www.nus.edu.sg/intro/slides/021111_1_Wilson%20Wong.ppt
What is protectable?
Functionality? - not protected - must be an "expression...of a set of instructions" - Autodesk Inc v Dyason (Aust): copying function of AutoCAD lock but not code (no infringement)
Program Structure? - (cf: plot elements in literary/dramatic works capable of protection) - eg. structural arrangements of modules and subroutines - yes if expression of idea, & no if ideas or functions: difficult line to draw - yes if organisation, sequence, arrangement or compilation - not protectable: elements of software which are: * ideas; * dictated by efficiency or external factors (eg h/w) specs, compatibility reqms, industry standards; or * public domain - not if similarity is due only to similar subject matter * analogy: drawing of a hand * eg any 2 word processors will have some structural similarities
We use the compatibility requirement reason. If we don't have that reason, then we have no right to create an identical implementation.
Casper
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Casper Hornstrup Sent: 18. januar 2006 23:06 To: 'ReactOS Development List' Subject: RE: [ros-dev] Bye bye
You MAY use the INFORMATION to implement the same functionality in ReactOS. You MAY NOT copy (and I'm talking about copy/pasting here) the work/implementation. This can be hard to do since one may think, why would I want to spend hours thinking up a new implementation when I've got a perfectly good one right in front of me? So to avoid this pitfall it is best to describe the functionality in plain English and let another developer implement the functionality using only the English text. A lot of work, but this is exactly why we have copyright. Microsoft did spend even more effort on the original implementation.
Casper
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Hartmut Birr Sent: 18. januar 2006 22:45 To: ReactOS Development List Subject: Re: [ros-dev] Bye bye
Royce Mitchell III wrote:
Hartmut Birr wrote:
Hi,
I don't agree completely with our legal policy. In my opinion, it is allowed to use reverse-engineering to find out interfaces or something like this. It isn't allowed to disassemble windows to study how the fast call entry works or to find out how the APC code is implemented. There exist some paper on the web. It is allowed to use the nice paper from David P. Probert (Windows Kernel Development). It isn't allowed to use the code from the dude called CrazyLord (Reverse Engineer).
This isn't quite fair, unfortunately. We've gone a long time without an explicit policy regarding this subject, mostly because we were all in agreement. You can't boot someone out because they violated a rule that wasn't made clear to them. OTOH, if our position is clearly stated and is violated then I agree - begone with them.
Looking on http://www.reactos.org/xhtml/en/dev_legalreview.htm http://www.reactos.org/xhtml/en/dev_legalreview.html, I found: <snip> C. Copyrights of Others The ReactOS Project depends on copyright law for the protection of its code, and by the same token, it respects the copyrights of others. Following are the policies of the ReactOS Project as they relate to copyright: <snip> Disassembly of object code is held to be a form of reverse engineering. Disassembled code listings should be treated with the same terms of license as the object code itself. <snip>
If I understand this correctly with my poor English, it isn't possible to disassembly a part of windows and uses this information to implement the same code in ReactOS.
- Hartmut
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I agree 200% on this. It is perfect solution for this kind of problems.
Though one detail I already discussed a little on irc - what is INFORMATION gained from disassembly? E.g. is some constant value an information which can be used in the code, even if it isn't documented or it's part of the code and thus needs to be "reinvented"?
WBR, Aleksey Bragin.
On Jan 19, 2006, at 1:06 AM, Casper Hornstrup wrote:
You MAY use the INFORMATION to implement the same functionality in ReactOS. You MAY NOT copy (and I'm talking about copy/pasting here) the work/implementation. This can be hard to do since one may think, why would I want to spend hours thinking up a new implementation when I've got a perfectly good one right in front of me? So to avoid this pitfall it is best to describe the functionality in plain English and let another developer implement the functionality using only the English text. A lot of work, but this is exactly why we have copyright. Microsoft did spend even more effort on the original implementation.
Casper
Steven Edwards wrote:
Hi,
On 1/17/06, Hartmut Birr osexpert@googlemail.com wrote:
Sometimes in the past, I didn't understand some changes, because the code didn't make sense for the current state of reactos and was not used. Currently, I've compared disassembled code from win2k and winxp with ReactOS. In my opinion, some of the developers do disassemble windows code to implement ReactOS.
Can you list offending code with a list of svn commits?
Thanks
-- Steven Edwards - ReactOS and Wine developer
Hi,
some days ago, I've seen the bug from r20911. It triggers a page fault after an invalid opcode exception from v86 mode. The invalid opcode exception in v86 mode can only occur if it is a real exception or if someone does setup a frame and calls the trap handler directly. I've found the function BadStack and some other things in syscall.S. The BadStack function don't make sense a the current state of ReactOS. I've compared the KiSysCallEntry with the dissembled code from WinXP:
WinXP: 004xxxxx off_004xxxxx: 004xxxxx B923000000 mov ecx,23h 004xxxxx 6A30 push 30h 004xxxxx 0FA1 pop fs 004xxxxx 8ED9 mov ds,ecx 004xxxxx 8EC1 mov es,ecx 004xxxxx 648B0D40000000 mov ecx,fs:[40h] 004xxxxx 8B6104 mov esp,[ecx+4] 004xxxxx 6A23 push 23h 004xxxxx 52 push edx 004xxxxx 9C pushfd 004xxxxx loc_004xxxxxx: 004xxxxx 6A02 push 2 004xxxxx 83C208 add edx,8 004xxxxx 9D popfd 004xxxxx 804C240102 or byte ptr [esp+1],2 004xxxxx 6A1B push 1Bh 004xxxxx FF350403DFFF push dword ptr [0FFDF0304h] 004xxxxx 6A00 push 0 004xxxxx 55 push ebp 004xxxxx 53 push ebx 004xxxxx 56 push esi 004xxxxx 57 push edi 004xxxxx 648B1D1C000000 mov ebx,fs:[1Ch] 004xxxxx 6A3B push 3Bh 004xxxxx 8BB324010000 mov esi,[ebx+124h] 004xxxxx FF33 push dword ptr [ebx] 004xxxxx C703FFFFFFFF mov dword ptr [ebx],0FFFFFFFFh 004xxxxx 8B6E18 mov ebp,[esi+18h] 004xxxxx 6A01 push 1 004xxxxx 83EC48 sub esp,48h 004xxxxx 81ED9C020000 sub ebp,29Ch 004xxxxx C6864001000001 mov byte ptr [esi+140h],1 004xxxxx 3BEC cmp ebp,esp 004xxxx1 0F85xxxxFFFF jne loc_004xxxx2 004xxxxx 83652C00 and dword ptr [ebp+2Ch],0 004xxxxx F6462CFF test byte ptr [esi+2Ch],0FFh 004xxxxx 89AE34010000 mov [esi+134h],ebp 004xxxxx 0F85xxxxFFFF jne loc_004xxxxx 004xxxxx loc_004xxxxx: 004xxxxx 8B5D60 mov ebx,[ebp+60h] 004xxxxx 8B7D68 mov edi,[ebp+68h] 004xxxxx 89550C mov [ebp+0Ch],edx 004xxxx3 C74508000DDBBA mov dword ptr [ebp+8],0BADB0D00h 004xxxxx 895D00 mov [ebp],ebx 004xxxxx 897D04 mov [ebp+4],edi 004xxxxx FB sti
004xxxx2 loc_004xxxx2: 004xxxxx 648B0D40000000 mov ecx,fs:[40h] 004xxxxx 8B6104 mov esp,[ecx+4] 004xxxxx 6A00 push 0 004xxxxx 6A00 push 0 004xxxxx 6A00 push 0 004xxxxx 6A00 push 0 004xxxxx 6A23 push 23h 004xxxxx 6A00 push 0 004xxxxx 6802020200 push 20202h 004xxxxx 6A1B push 1Bh 004xxxxx 6A00 push 0 004xxxxx E9xxxx0000 jmp loc_00407F1A
ReactOS: 80064375 <_KiFastCallEntry>: _KiFastCallEntry:
// ==================== UNIQUE SYSENTER STUB. DO NOT DUPLICATE ============// /* Set FS to PCR */ mov ecx, KGDT_R0_PCR 80064375: b9 30 00 00 00 mov $0x30,%ecx mov fs, cx 8006437a: 8e e1 movl %ecx,%fs
/* Set DS/ES to Kernel Selector */ mov ecx, KGDT_R0_DATA 8006437c: b9 10 00 00 00 mov $0x10,%ecx mov ds, cx 80064381: 8e d9 movl %ecx,%ds mov es, cx 80064383: 8e c1 movl %ecx,%es
/* Set the current stack to Kernel Stack */ mov ecx, [fs:KPCR_TSS] 80064385: 64 8b 0d 40 00 00 00 mov %fs:0x40,%ecx mov esp, ss:[ecx+KTSS_ESP0] 8006438c: 36 8b 61 04 mov %ss:0x4(%ecx),%esp
/* Set up a fake INT Stack. */ push KGDT_R3_DATA + RPL_MASK 80064390: 6a 23 push $0x23 push edx /* Ring 3 SS:ESP */ 80064392: 52 push %edx pushf /* Ring 3 EFLAGS */ 80064393: 9c pushf push 2 /* Ring 0 EFLAGS */ 80064394: 6a 02 push $0x2 add edx, 8 /* Skip user parameter list */ 80064396: 83 c2 08 add $0x8,%edx popf /* Set our EFLAGS */ 80064399: 9d popf or dword ptr [esp], EFLAGS_INTERRUPT_MASK /* Re-enable IRQs in EFLAGS, to fake INT */ 8006439a: 81 0c 24 00 02 00 00 orl $0x200,(%esp) push KGDT_R3_CODE + RPL_MASK 800643a1: 6a 1b push $0x1b push KUSER_SHARED_SYSCALL_RET 800643a3: 68 04 03 fe 7f push $0x7ffe0304
/* Setup the Trap Frame stack */ push 0 800643a8: 6a 00 push $0x0 push ebp 800643aa: 55 push %ebp push ebx 800643ab: 53 push %ebx push esi 800643ac: 56 push %esi push edi 800643ad: 57 push %edi push KGDT_R3_TEB + RPL_MASK 800643ae: 6a 3b push $0x3b
/* Save pointer to our PCR */ mov ebx, [fs:KPCR_SELF] 800643b0: 64 8b 1d 1c 00 00 00 mov %fs:0x1c,%ebx
/* Get a pointer to the current thread */ mov esi, [ebx+KPCR_CURRENT_THREAD] 800643b7: 8b b3 24 01 00 00 mov 0x124(%ebx),%esi
/* Set the exception handler chain terminator */ push [ebx+KPCR_EXCEPTION_LIST] 800643bd: ff 33 pushl (%ebx) mov dword ptr [ebx+KPCR_EXCEPTION_LIST], -1 800643bf: c7 03 ff ff ff ff movl $0xffffffff,(%ebx)
/* Use the thread's stack */ mov ebp, [esi+KTHREAD_INITIAL_STACK] 800643c5: 8b 6e 18 mov 0x18(%esi),%ebp
/* Push previous mode */ push UserMode 800643c8: 6a 01 push $0x1
/* Skip the other registers */ sub esp, 0x48 800643ca: 83 ec 48 sub $0x48,%esp
/* Hack: it seems that on VMWare someone damages ES/DS on exit. Investigate! */ mov dword ptr [esp+KTRAP_FRAME_DS], KGDT_R3_DATA + RPL_MASK 800643cd: c7 44 24 38 23 00 00 movl $0x23,0x38(%esp) 800643d4: 00 mov dword ptr [esp+KTRAP_FRAME_ES], KGDT_R3_DATA + RPL_MASK 800643d5: c7 44 24 34 23 00 00 movl $0x23,0x34(%esp) 800643dc: 00
/* Make space for us on the stack */ sub ebp, 0x29C 800643dd: 81 ed 9c 02 00 00 sub $0x29c,%ebp
/* Write the previous mode */ mov byte ptr [esi+KTHREAD_PREVIOUS_MODE], UserMode 800643e3: c6 86 d7 00 00 00 01 movb $0x1,0xd7(%esi)
/* Sanity check */ cmp ebp, esp 800643ea: 39 e5 cmp %esp,%ebp jnz BadStack 800643ec: 0f 85 5e ff ff ff jne 80064350 <BadStack>
/* Flush DR7 */ and dword ptr [ebp+KTRAP_FRAME_DR7], 0 800643f2: 83 65 2c 00 andl $0x0,0x2c(%ebp)
/* Check if the thread was being debugged */ test byte ptr [esi+KTHREAD_DEBUG_ACTIVE], 0xFF 800643f6: f6 46 03 ff testb $0xff,0x3(%esi)
/* Jump to shared code or DR Save */ //jnz Dr_FastCallDrSave jmp SharedCode 800643fa: eb 5b jmp 80064457 <SharedCode>
SharedCode: mov [esi+KTHREAD_TRAP_FRAME], ebp 80064457: 89 ae 10 01 00 00 mov %ebp,0x110(%esi)
/* Set the trap frame debug header */ SET_TF_DEBUG_HEADER 8006445d: 8b 5d 60 mov 0x60(%ebp),%ebx 80064460: 8b 7d 68 mov 0x68(%ebp),%edi 80064463: 89 55 0c mov %edx,0xc(%ebp) 80064466: c7 45 08 00 0d db ba movl $0xbadb0d00,0x8(%ebp) 8006446d: 89 5d 00 mov %ebx,0x0(%ebp) 80064470: 89 7d 04 mov %edi,0x4(%ebp)
80064350 <BadStack>: 80064350: 64 8b 0d 40 00 00 00 mov %fs:0x40,%ecx 80064357: 36 8b 61 04 mov %ss:0x4(%ecx),%esp 8006435b: 6a 00 push $0x0 8006435d: 6a 00 push $0x0 8006435f: 6a 00 push $0x0 80064361: 6a 00 push $0x0 80064363: 6a 23 push $0x23 80064365: 6a 00 push $0x0 80064367: 68 02 02 02 00 push $0x20202 8006436c: 6a 1b push $0x1b 8006436e: 6a 00 push $0x0 80064370: e9 1f 0c 00 00 jmp 80064f94 <_KiTrap6>
The ReactOS code and the WinXP code is nearly the same. The stack check and the invalid opcode exception is equal. The trap frame is created in the same sequence. The debug mark 0xbadb0d00 is the same. On other places we use always something like 0xdeadbeef or 0xceadbeef. Each revision of syscall.S makes our code closer to the Windows code. In some days we have exactly the same binary code. I know that the frame, KTHREAD and the PCR layout is predefined. Some of the used informations are not public. In my opinion, the fast call entry code is copied step by step from the disassembled Windows code.
- Hartmut
Hartmut Birr wrote:
The ReactOS code and the WinXP code is nearly the same.
As a matter of fact, it is, although more similar to the Win2K3 code.
The stack check and the invalid opcode exception is equal.
Yes, when I analyzed the fast call code (yes I looked at disassembly) I saw that check, and I copied it. Note however, that there is only one way to check the stack: cmp ebp, esp. Unless you want to consider cmp esp, ebp as an alternate method.
The trap frame is created in the same sequence.
You can only create a trap frame in one way, it has a defined layout. I point out a difference which proves I don't just copy/paste code. Somewhere in the handler, windows does this:
mov ecx, fs:[0] push ecx
My code does simply: push fs:[0]
I would also like to point out that unlike certain code which I've found in ReactOS (The old ftol implementation comes to mind) which comes from assembly, my code is clearly commented, organized and structured, and shows that I know what I was doing any not merely copy/pasting some assembly. This is much unlike the old ftol code, which was simply an exact 100% duplicate of the windows code, with 0 comments and using hardcoded values which were not explained (clearly showing that the implementer had no idea of what the code did).
The debug mark 0xbadb0d00 is the same.
Yes, this is the debug mark found in windows KTRAP_FRAMES. It is a known value to any kernel/system developer for Windows that has analyzed many crashdumps.
On other places we use always something like 0xdeadbeef or 0xceadbeef.
Wow, nice argument. Do you realize that 0xdeadbeef is what *windows* uses for memory that has been freed, and 0xceadbeef for memory that hasn't been used yet (or something according to those lines)? So you're saying "0xbadb0d00 is bad because Windows uses it..but 0xdeadbeef is good because..Windows uses it"?
Each revision of syscall.S makes our code closer to the Windows code.
On the contrary, the syscall.S code was written by myself about a year and a half ago, and contained some parts of the code which I had copied without fully understanding their use (not from Windows, but from crazylord/elicz). After more then a year has passed, I finally got a much deeper understanding of all the intricacies involved, and started using more constants instead of hardcoded definitions, started adding more comments, and turned raw binary code into complex generic macros which could generate the code we wanted. I very much doubt that when you look at KiServiceExit in IDA you see the sequence of comments and macros that I've created. The fact I've been able to make everything much more generic and controlled only proves the fact that the implementation is mine much more then a copy/paste job. And yes, for the record, I fully admit that some parts (which I want to point out were written 18 months ago) were copied from elicz's disasembly. But when we are talkig about system-level assembly, there aren't 10 ways to do something, except to use different registers and pretend to be different. And another thing, 3 of the DBG checks that I added are becaused I noticed them during a late-nite debugging session in WinDBG. I was trying a user-mode kernel exploit which modified the trap frame, and this led to some int3s in the code. I noticed that some checks were being done (sanity checks, not anything functional), and I added them in ReactOS too.
In some days we have exactly the same binary code.
As I said, the code hasn't changed much since its original implementation more then a year ago. Since then, 90% of the chances made the code more compact in source-form, added comments, generalized it and made it accesible through macros.
I know that the frame, KTHREAD and the PCR layout is predefined. Some of the used informations are not public.
I'd like to know what isn't public and that we're using. When my debugger hits an assertion in some code, it becomes public that "Windows checks if a == b". Because that check is a public check, it's visible by anyone hitting it.
In my opinion, the fast call entry code is copied step by step from the disassembled Windows code.
I've addressed this already. I think your reaction (to remove your name) and to post messages about "honour" was more then excessive and was more dramatic then anything. Removing your name from ReactOS does not change the fact you wrote that code, and your name would be added back anyways as a copyright owner, unless of course you want to make it "Public Domain". So unfortunately, I don't see your reaction of removing your name as anything else but a PR coup. Even if had the entire code actually been copied, you should've at least e-mailed the person responsible/project, talked things out and gotten an explanation. I hope you don't take this offensively, but I simply think your reaction was excessive and dramatic. And the reason I'm saying this is because I've had similar reactions in the past in this project, and I've learnt from others that they don't achieve much (I would like to thank KJK for this :))
- Hartmut
Best regards, Alex Ionescu
PS. I apologize for my lack of presence in the matter. I have re-started school and I have almost no time anymore to read emails or participate much in ReactOS for the next months, which is why I wanted to finish up some commits these last two weeks. For any urgent matters, please email me directly (thank you Royce).
Alex Ionescu wrote:
Wow, nice argument. Do you realize that 0xdeadbeef is what *windows* uses for memory that has been freed, and 0xceadbeef for memory that hasn't been used yet (or something according to those lines)? So you're saying "0xbadb0d00 is bad because Windows uses it..but 0xdeadbeef is good because..Windows uses it"?
FYI, Linux uses DeadBeef also. James
Hi,
Speaking as someone that is mostly ignorant of kernel internals, lets pretend I am a judge....
On 1/18/06, Alex Ionescu ionucu@videotron.ca wrote:
Yes, when I analyzed the fast call code (yes I looked at disassembly) I saw that check, and I copied it.
Why did you have to do this? Is it not possible to write a driver that abuses fastcall to make a mostly working implementation without having to 1. look at and 2. copy the existing object code of Windows?
I would also like to point out that unlike certain code which I've found in ReactOS (The old ftol implementation comes to mind) which comes from assembly, my code is clearly commented, organized and structured, and shows that I know what I was doing any not merely copy/pasting some
OK so someone else sneaked something in that violates the rules and it was not caught. Lets just check your argument for a moment and say you could be wrong about your development methods. Being ..."clearly commented, organized and structured..." does not amount to a hill of beans if I am violating the law and or project rules. I can make bank robbing plans that are "...clearly commented, organized and structured..." I don't think that will gain me much ground in court.
assembly. This is much unlike the old ftol code, which was simply an exact 100% duplicate of the windows code, with 0 comments and using hardcoded values which were not explained (clearly showing that the implementer had no idea of what the code did).
Can you explain to me why the magic numbers match Windows in ke/i386/trap.s? Like I said I am mostly ignorant of kernel internals but this was asked of me...
The code in ke/i386/trap.s looks kind of suspicious, because it uses alot of magic numbers...
/* Push previous mode */ push UserMode
/* Skip the other registers */ sub esp, 0x48
/* Hack: it seems that on VMWare someone damages ES/DS on exit. Investigate! */ mov dword ptr [esp+KTRAP_FRAME_DS], KGDT_R3_DATA + RPL_MASK mov dword ptr [esp+KTRAP_FRAME_ES], KGDT_R3_DATA + RPL_MASK
/* Make space for us on the stack */ sub ebp, 0x29C
ie. why 0x29C, why 0x48?
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On 1/19/06, Steven Edwards winehacker@gmail.com wrote:
Hi,
Speaking as someone that is mostly ignorant of kernel internals, lets pretend I am a judge....
You are not a judge with years of experience in law. Whether or not you have any kernel internal knowledge is also irrelevant to this thought experiment.
On 1/18/06, Alex Ionescu ionucu@videotron.ca wrote:
Yes, when I analyzed the fast call code (yes I looked at disassembly) I saw that check, and I copied it.
Why did you have to do this? Is it not possible to write a driver that abuses fastcall to make a mostly working implementation without having to 1. look at and 2. copy the existing object code of Windows?
Alex clearly stated that there is only one way to perform that stack check, let's quote him properly:
"Note however, that there is only one way to check the stack: cmp ebp, esp. Unless you want to consider cmp esp, ebp as an alternate method."
As Casper said, it is legal to use that information, but not legal to *copy/paste* it into ReactOS. Alex clearly comprehends what that bit of assembly does.
I would also like to point out that unlike certain code which I've found in ReactOS (The old ftol implementation comes to mind) which comes from assembly, my code is clearly commented, organized and structured, and shows that I know what I was doing any not merely copy/pasting some
OK so someone else sneaked something in that violates the rules and it was not caught. Lets just check your argument for a moment and say you could be wrong about your development methods. Being ..."clearly commented, organized and structured..." does not amount to a hill of beans if I am violating the law and or project rules. I can make bank robbing plans that are "...clearly commented, organized and structured..." I don't think that will gain me much ground in court.
This analogy is invalid. The legality of this issue stems directly from whether or not he wrote the code. Robbing a bank is _always_ illegal, writing code is only illegal if you copy/paste it from a legitimate author, or implement a patented method.
Alex's structured and commented code demonstrates comprehension. In this case, where the code's function is clear, and constrained by implementation details, the code will be similar by anyone who implements it. Alex's comments and code structure shows that he understands what is going on in the assembly, and most likely shows that he wrote the code, as opposed to just copy/pasting existing code.
assembly. This is much unlike the old ftol code, which was simply an exact 100% duplicate of the windows code, with 0 comments and using hardcoded values which were not explained (clearly showing that the implementer had no idea of what the code did).
Can you explain to me why the magic numbers match Windows in ke/i386/trap.s? Like I said I am mostly ignorant of kernel internals but this was asked of me...
The code in ke/i386/trap.s looks kind of suspicious, because it uses alot of magic numbers...
It only looks suspicious since you are not a kernel developer. Again, not something a judge would concern himself with. Now the prosecutor.....
/* Push previous mode */ push UserMode /* Skip the other registers */ sub esp, 0x48 /* Hack: it seems that on VMWare someone damages ES/DS on exit.Investigate! */ mov dword ptr [esp+KTRAP_FRAME_DS], KGDT_R3_DATA + RPL_MASK mov dword ptr [esp+KTRAP_FRAME_ES], KGDT_R3_DATA + RPL_MASK
/* Make space for us on the stack */ sub ebp, 0x29Cie. why 0x29C, why 0x48?
Since he is making room on the stack for another frame, this is a predefined size.
-- Steven Edwards - ReactOS and Wine developer
Alex's explanation (in conjunction with Casper's clarification of our rules) was enough to satisfy me. I do not think Alex violated the project rules, and the legality of his code can only be decided in a court of law, so we are just wasting our time talking about it any further. Now, I do agree he could have used the safer "clean-room" method, but I'm not convinced that it would have yielded a significantly different implementation, and we might still be in the same position.
IANAL, BIPOOI, WD -- (but I play one on IRC) ;0)
WaxDragon wrote:
Alex clearly stated that there is only one way to perform that stack check, let's quote him properly:
"Note however, that there is only one way to check the stack: cmp ebp, esp. Unless you want to consider cmp esp, ebp as an alternate method."
And does exist only one way to handle the wrong stack? Alex said nothing about this.
Every developer handles the wrong stack in the same way like Windows. It is absolutely clearly, that a wrong stack must result in a v86 exception.
Sorry WD, the code was simply inserted by copy and paste. If you don't like to see something, you will see nothing.
As Casper said, it is legal to use that information, but not legal to *copy/paste* it into ReactOS. Alex clearly comprehends what that bit of assembly does.
If it is legal by the ReactOS policy to disassemble every piece of windows code to implement ReactOS, I would like it if ReactOS can put this on the home page as the first topic.
This type of reverse-engineering is prohibited by law in many countries. It gives M$ a very easy way to kick the project.
I can't believe that the project was started with this justification.
My recommendation for ReactOS is:
1) Review the ReactOS project development policy
2) Review all code
3) Remove all code, which don't match to the policy.
- Hartmut
Hi Hartmut,
On 1/19/06, Hartmut Birr osexpert@googlemail.com wrote:
If it is legal by the ReactOS policy to disassemble every piece of windows code to implement ReactOS, I would like it if ReactOS can put this on the home page as the first topic.
This type of reverse-engineering is prohibited by law in many countries. It gives M$ a very easy way to kick the project.
I can't believe that the project was started with this justification.
No this is clearly a violation of the policy
From Section C of the ReactOS IP Statement (C. Copyrights of Others)
....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.
My recommendation for ReactOS is:
- Review the ReactOS project development policy
I think the policy is clear that this type of dirty-room reverse engineering should be used as a last resort only.
- Review all code
Agreed
- Remove all code, which don't match to the policy.
Agreed
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Steven Edwards wrote:
Hi Hartmut,
On 1/19/06, Hartmut Birr osexpert@googlemail.com wrote:
If it is legal by the ReactOS policy to disassemble every piece of windows code to implement ReactOS, I would like it if ReactOS can put this on the home page as the first topic.
This type of reverse-engineering is prohibited by law in many countries. It gives M$ a very easy way to kick the project.
I can't believe that the project was started with this justification.
No this is clearly a violation of the policy
From Section C of the ReactOS IP Statement (C. Copyrights of Others)
....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.
My recommendation for ReactOS is:
- Review the ReactOS project development policy
I think the policy is clear that this type of dirty-room reverse engineering should be used as a last resort only.
Personally, I think that if the project is to survive (and I suspect it may be too late) the policy should be:
If you look at a piece of windows in a disassembler, you MUST NOT implement that code for ReactOS. You can write a document describing what is necessary and put that document in SVN. Some other developer(s) MUST do the implementation-- furthermore, they MUST do the implementation without discussing it with you-- they MUST work strictly from the document you wrote.
That may be harsh, and slow down progress, but I suspect that is the only way ReactOS would survive a legal challenge.
Probably, to be safe, we'd actually need to say:
If you look at windows in a disassembler, you MUST NOT write code for ReactOS. Sorry, thats the way it is. But wait! You can still help with the project by looking at this list (link to list) of things we need to know in order to be compatible with windows. Then, discover this information using the disassembler, and write a specification (plain English, no code or pseudo-code please) that describes what we need to know and submit it to the project for inclusion in our repository. One of our developers will then (eventually) get around to using your specification to correct our implementation to be compatible.
I'm not sure we'd ever get that through... but that is the way it should be.
Of course, I'm not a lawyer ... so what do I know.
Thanks,
Joseph
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Joseph Galbraith wrote: [snip]
Probably, to be safe, we'd actually need to say:
If you look at windows in a disassembler, you MUST NOT write code for ReactOS. Sorry, thats the way it is. But wait! You can still help with the project by looking at this list (link to list) of things we need to know in order to be compatible with windows. Then, discover this information using the disassembler, and write a specification (plain English, no code or pseudo-code please) that describes what we need to know and submit it to the project for inclusion in our repository. One of our developers will then (eventually) get around to using your specification to correct our implementation to be compatible.
I'm not sure we'd ever get that through... but that is the way it should be.
Of course, I'm not a lawyer ... so what do I know.
Pseudocode should be acceptable; if you are looking at disassembly, and write pseudo-C pseudocode, you are, in effect, doing the same thing as writing it in English. The end will be code that is still as original as from a written English document. There's little difference between the two following items:
"The code works by copying a string from memory location A to memory location B, adding an extra byte after each character in the string to describe attributes."
And:
=====
string_pointer A string_pointer B
while A[location] != NULL BYTE { B[A's location * 2] = A[location] B[(A's Location * 2)+1] = WHITE ON BLACK DESCRIPTION (e.g., 70) }
=====
That is not valid code, and gets pretty much the same thing across but in a different manner. Accompanied by more verbose English to fill in some of the terseness, it's a perfect solution that does not compromise any legal coding.
- Mike
That as I understand it, is the policy that IBM used for reverse-engineering MS Wind3.x for IBM OS/2. So it's well understood.
Wesley Parish
On Fri, 20 Jan 2006 06:58, Joseph Galbraith wrote:
Steven Edwards wrote:
Hi Hartmut,
On 1/19/06, Hartmut Birr osexpert@googlemail.com wrote:
If it is legal by the ReactOS policy to disassemble every piece of windows code to implement ReactOS, I would like it if ReactOS can put this on the home page as the first topic.
This type of reverse-engineering is prohibited by law in many countries. It gives M$ a very easy way to kick the project.
I can't believe that the project was started with this justification.
No this is clearly a violation of the policy
From Section C of the ReactOS IP Statement (C. Copyrights of Others)
....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.
My recommendation for ReactOS is:
- Review the ReactOS project development policy
I think the policy is clear that this type of dirty-room reverse engineering should be used as a last resort only.
Personally, I think that if the project is to survive (and I suspect it may be too late) the policy should be:
If you look at a piece of windows in a disassembler, you MUST NOT implement that code for ReactOS. You can write a document describing what is necessary and put that document in SVN. Some other developer(s) MUST do the implementation-- furthermore, they MUST do the implementation without discussing it with you-- they MUST work strictly from the document you wrote.
That may be harsh, and slow down progress, but I suspect that is the only way ReactOS would survive a legal challenge.
Probably, to be safe, we'd actually need to say:
If you look at windows in a disassembler, you MUST NOT write code for ReactOS. Sorry, thats the way it is. But wait! You can still help with the project by looking at this list (link to list) of things we need to know in order to be compatible with windows. Then, discover this information using the disassembler, and write a specification (plain English, no code or pseudo-code please) that describes what we need to know and submit it to the project for inclusion in our repository. One of our developers will then (eventually) get around to using your specification to correct our implementation to be compatible.
I'm not sure we'd ever get that through... but that is the way it should be.
Of course, I'm not a lawyer ... so what do I know.
Thanks,
Joseph _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I have steped in on other matters where a project developer ( was Alex also ) was attacked. Seeing that these "growing pains" of the project seem to be re-occuring ( and in diferent areas of the project ). I realize I am an outsider of the project, but none the less, i feel that an important problem is starting to rear its little ugly head: there aren't any non-developer types there to help deal with sticking to policy ( because from what i can see, the developers are to envolved with code to handle policy) and I think that in order to prevent further contamination of the code, there needs to be a single (or group) individual responsable for collecting information on how MS handles things.
In this matter, I have to say that I agree with WD and think Alex's actions were ok. He showed that if required to re-write his code, he would at least have enough of an understanding to write something that worked. I feel that Hartmut's actions are hostile, and questionable, though I do agree that the binary code doesn't lie, and a major portion of React OS binary is similar to MS'es, but in duplicating functionality, this should be expected...
brian
I agree with what's been said by Alex, and Brian. Hartmut, all this little spat has done has been to shove yet -more- negativity on the project. When a problem like this occurs, you don't turn tail and just run off, expecting it to be solved in your absence. Instead, you stick around, and improve things for the better. In fact, I'd liken your outburst to a tantrum, and I personally think it has done the project more harm than good, especially considering this ML is public.
Fact is, ReactOS aims to duplicate the functionality of Windows. In doing so, I believe it is expected that a certain amount of things cannot be done a different way than to how Microsoft has implemented them. Open up Linux, and I'm sure you'll see LOTS of pieces of code that strikingly resemble UNIX.
On 1/19/06, Brian briandabrain@gmail.com wrote:
I have steped in on other matters where a project developer ( was Alex also ) was attacked. Seeing that these "growing pains" of the project seem to be re-occuring ( and in diferent areas of the project ). I realize I am an outsider of the project, but none the less, i feel that an important problem is starting to rear its little ugly head: there aren't any non-developer types there to help deal with sticking to policy ( because from what i can see, the developers are to envolved with code to handle policy) and I think that in order to prevent further contamination of the code, there needs to be a single (or group) individual responsable for collecting information on how MS handles things.
In this matter, I have to say that I agree with WD and think Alex's actions were ok. He showed that if required to re-write his code, he would at least have enough of an understanding to write something that worked. I feel that Hartmut's actions are hostile, and questionable, though I do agree that the binary code doesn't lie, and a major portion of React OS binary is similar to MS'es, but in duplicating functionality, this should be expected...
brian
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- "I had a handle on life, but then it broke"
I like Joseph's idea, but maybe a little less strict, or maybe set up to that those are fall back rules for testing for tainting. I, in oppose, think the reverser should be aloud to comunicate, write psudocode, and documentation, but should be bound to NEVER reveal exact code or publish reversed code. The absolute line should be drawn at programs design to probe actual running windows, because the probe code is writen by the dev.
The most of the arguments to reversed knoledege are over constants. THIS FUSS IS HURTING THE PROJECT!!! If you want compatability with diferent constants, please lay off the coke. These constants were established by people being paid to do such, so they should have done their job well in establishing these. If they didn't, then it would be best to change it in ROS; else I feel it would best to stick with this advice: "if it ain't broke, don't fix it!"
brian
ps: if this childish crap goes on much longer, Im gonna try to join the project as a "parrental suppervisor"
I never stated it could not be written in another way. I stated that similar binary code should be expected. I guess i have to talk 'baby'.
2 + 2 = 4 two plus two equals four
I don't think i should have to talk like this to a developer, especialy to a developer. in theory, it could be done using diferent instructions, and use diferent regesters, but what would be the point. if it was not copied, but he personaly wrote this code. I am not trying to say it cant be written another way, im just saying dont point the finger at the victom, just because he was in the same room as the murderer.
brian
There is a precedent - the AT&T vs UC@Berkeley case.
http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/930303.ruling.txt
"Plaintiff's first argument is that Defendants have copied the filenames and header files from 32V. Defendants insist that filenames and the contents of header files can be readily printed from Plaintiff's binary code (Joint Decl. at 28.1.1.), which Plaintiff has apparently distributed without restriction on redistribution. In addition, some of this code is available in reference manuals distributed by Plaintiff. (Carson Reply Aff. at 9.)"
"After reviewing the affidavits of Plaintiff's and Defendants, experts, a great deal of uncertainty remains as to what trade secrets Net2 might contain. One fact does seem clear: the header files, filenames, and function names used by Defendants are not trade secrets. Defendants could have printed these off of any of the thousands of unrestricted copies of Plaintiff's binary object code. (Kashtan Aff. at 9-11.) Moreover, the nonfunctional elements of the code, such as comments, cannot be trade secrets because these elements are minimal and confer no competitive advantage on Defendants. The copied elements that contain instructions, such as BREAD and CPIO, might perhaps be trade secrets, but Defendants' experts have argued persuasively that these instructions are either in the public domain or otherwise exempt. As Defendants have repeatedly emphasized, much of 32V seems to be publicly available."
"On the present record, however, it is impossible to determine whether the overall organization of Net2 has been disclosed. The record itself contains little information directly pertinent to this issue. Moreover, the parties' submissions hint that some of 32V's organization may already be publicly available. Berkeley has apparently released nonproprietary programs such as Net1 since 1987 (Regents Am. Opp'g Br. at 13), programs that presumably have divulged at least some information about 32V's organization."
In short, copy-and-paste is not the way to do things - clean-room is perfectly legit and there's already quite a bit of that going on in the MS Windows developer community anyway.
But when there's no way to get functionality without using similar code and similar data (such as headers) which are in the public domain it seems anyway, it's pointless worrying about it, let alone arguing about it. If Microsoft wants developers, they have to expose their APIs and turn a blind eye to publication of undocumented APIs - and if that disclosure is useful to a competitor, well, it turns out that Microsoft's maintaining its monopoly rests on keeping customers worldwide horribly insecure.
There's more than one way to skin a cat, and Microsoft's limping.
Just my 0.0c - hyperinflation of course! ;)
Wesley Parish
On Fri, 20 Jan 2006 08:39, Brian wrote:
I never stated it could not be written in another way. I stated that similar binary code should be expected. I guess i have to talk 'baby'.
2 + 2 = 4 two plus two equals four
I don't think i should have to talk like this to a developer, especialy to a developer. in theory, it could be done using diferent instructions, and use diferent regesters, but what would be the point. if it was not copied, but he personaly wrote this code. I am not trying to say it cant be written another way, im just saying dont point the finger at the victom, just because he was in the same room as the murderer.
brian
Then provide proof that it can't be written another way. Also, no one has mentioned why ReactOS need this code. Which driver or application won't work without this code?
Casper
_____
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Brian Sent: 19. januar 2006 18:50 To: ReactOS Development List Subject: Re: [ros-dev] Bye bye
I have steped in on other matters where a project developer ( was Alex also ) was attacked. Seeing that these "growing pains" of the project seem to be re-occuring ( and in diferent areas of the project ). I realize I am an outsider of the project, but none the less, i feel that an important problem is starting to rear its little ugly head: there aren't any non-developer types there to help deal with sticking to policy ( because from what i can see, the developers are to envolved with code to handle policy) and I think that in order to prevent further contamination of the code, there needs to be a single (or group) individual responsable for collecting information on how MS handles things.
In this matter, I have to say that I agree with WD and think Alex's actions were ok. He showed that if required to re-write his code, he would at least have enough of an understanding to write something that worked. I feel that Hartmut's actions are hostile, and questionable, though I do agree that the binary code doesn't lie, and a major portion of React OS binary is similar to MS'es, but in duplicating functionality, this should be expected...
brian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hartmut Birr wrote:
This type of reverse-engineering is prohibited by law in many countries. It gives M$ a very easy way to kick the project.
I can't believe that the project was started with this justification.
Reverse-engineering covers a broad scope; however, even this type of reverse-engineering is permitted. Nobody can prohibit you from looking at anything, as that would be unconstitutional (in the States). However, they *can* prohibit you from copying the code. Note that copying the code doesn't state "Copy and Paste". If a substantial CHUNK of code is exactly identical, then there's question. However, stacks and other things that are predefined sizes, cannot be claimed to be violation of any copyrights; If I want to skip past 4 parameters on the stack, for example, and that stack has 4 bytes per item, then I must jump back 16 bytes. That doesn't matter what the implementation is, those are the mathematical facts.
However, that having been said, while "clean room" development, so to speak, takes longer, it is preferred in commercial projects so as to avoid the legal questions. However, when using this approach, much more documentation must be done to prove the method and document the process.
FLOSS projects that have developers outside of copyright/patent enforcing countries can pretty well do as they wish; their code cannot be prosecuted since they hold the copyright. However, in that case, infringing code can be held against the /distributor/ of the code, and that can in turn become a very messy legal spat.
Clean room RE processes really are the only way to make the mess go away; but it will significantly slow development compared to more "dirty room" methods. It does, however, eliminate many possibilities and questions as to how code works and how it doesn't infringe upon others.
- Mike
On 1/19/06, WaxDragon waxdragon@gmail.com wrote:
You are not a judge with years of experience in law. Whether or not you have any kernel internal knowledge is also irrelevant to this thought experiment.
No but I am someone trying to be objective that has spent a good part of the past few years reviewing case history for reverse engineering cases. Its more than we are going tot get from some judges.
Why did you have to do this? Is it not possible to write a driver that abuses fastcall to make a mostly working implementation without having to 1. look at and 2. copy the existing object code of Windows?
Alex clearly stated that there is only one way to perform that stack check, let's quote him properly:
"Note however, that there is only one way to check the stack: cmp ebp, esp. Unless you want to consider cmp esp, ebp as an alternate method."
As Casper said, it is legal to use that information, but not legal to *copy/paste* it into ReactOS. Alex clearly comprehends what that bit of assembly does.
Once again he may have stated this but he also states he disassembled Windows. The issue is the methods used to gather the information. Reverse engineering is legal if there is no other method to gather the information which is why I clearly asked "Was there no other way to get this information" or let me put it another way....
Alex: did you even bother doing some sort of clean room examination of Windows behavior based on third party drivers or some sort of testing or was IDA your first step? Checked Microsoft driver assertions and debug symbols don't count.
OK so someone else sneaked something in that violates the rules and it was not caught. Lets just check your argument for a moment and say you could be wrong about your development methods. Being ..."clearly commented, organized and structured..." does not amount to a hill of beans if I am violating the law and or project rules. I can make bank robbing plans that are "...clearly commented, organized and structured..." I don't think that will gain me much ground in court.
This analogy is invalid. The legality of this issue stems directly from whether or not he wrote the code. Robbing a bank is _always_ illegal, writing code is only illegal if you copy/paste it from a legitimate author, or implement a patented method.
No its perfectly a valid question. In law there is this concept called Mens Rea which means intent. Was his intent to create a independent unique work he himself created and he just needed the information for compatibly reasons or did he intend to just make it work without caring of the consequences to everyone else. Hence the question above. Was IDA the first step or the last?
Alex's structured and commented code demonstrates comprehension. In this case, where the code's function is clear, and constrained by implementation details, the code will be similar by anyone who implements it. Alex's comments and code structure shows that he understands what is going on in the assembly, and most likely shows that he wrote the code, as opposed to just copy/pasting existing code.
Just because he understands the code now is irrelevant. Its the method of which that understanding came. Because our work is going to be similar to windows the arguments about a derived work hangs upon the notion that we are independently creating our own implementation rather than looking at the original. We can read documentation about the original all day long, we can examine applications and drivers that use the original all day long but when we start to crack open the book of the original implementation we run the legal risk of being declared a derived work.
It only looks suspicious since you are not a kernel developer. Again, not something a judge would concern himself with. Now the prosecutor.....
/* Skip the other registers */ sub esp, 0x48
<snip>
ie. why 0x29C, why 0x48?
Since he is making room on the stack for another frame, this is a predefined size.
Hmm ok. So another size won't work? Where is it predefined? I ask not to accuse but to try to understand to be fair to all parties involved. But according to Hartmut this is a clear case of copy and paste. This is why we cannot allow this to continue. If dirty-room reverse engineering was the last resort then it would be a original implementation
further. Now, I do agree he could have used the safer "clean-room" method, but I'm not convinced that it would have yielded a significantly different implementation, and we might still be in the same position.
You admit that his implementation was not based on "clean-room". My question once again was why did it have to be dirty room? If there is no other option for making a compatible implementation then this discussion holds no water but if by your own words he could have used a safer method then there is a problem.
So we are back to the first question. What development methods were used. IDA first or last?
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Hi,
I'm going to answer generically, not point-by-point, since I don't have much time, but I hope I can cover everything:
1) Those magic sizes were calculated in my head and I didn't have time to make them into constants as I did many of them. 0x29C is the pre-defined value of NPX_FRAME_LENGTH + KTRAP_FRAME_LENGTH. 0x48 is the differerence in the KTRAP_FRAME between the registers that we will skip. I could've done (KTRAP_FRAME_XXX - KTRAP_FRAME_YYY).
2) This is not a matter of driver compatibility. The fast system call stub is a mostly hardware-defined entrypoint, handled by low-level software logic. In implementing it, there are only 3 available sources of information: Whatever minimal info the Intel manual gives, the Linux sources, the Windows kernel binary. It is almost simply impossible to "guess" how the stub should work. Filip tried to make it work more then a year ago, and even he gave up (the AMD version), beacuse it is simply too hard and confusing unless you have some available code to look at. As such, my first and foremost source was the Linux source code. It helped me understand how to setup the LSTAR MSR register, as well as the other register values. Then, through several mailing list posts, I was able to understand some bugs in the way ReactOS had its segments set up, which caused problems in the code. Then, to understand the way Windows chose between INT2E and SYSENTER, I found a document online written by a person called Elicz, which described the stub and what it should do, much in the same way people argued "clean-room reverse engineering" is done. With this information, I was able to write more then 85% of the stub. My next, and final remaining possible step, was to use IDA to look at the Windows code. I used it as a learning tool, not as a copying tool. It is hard to argue that what I did was "Reverse-engineering", which, to my knowledge, implies taking something apart to re-create it, since this usually implies converting the assembly code to functional C code or otherwise. But I don't view as looking at assembly in order to understand a low-level hardware interface as "reverse engineering". And yes, as described above, it -was- my last choice. Additionally, the parts which were supposedly "copied" are NOT part of the functional part of the code. They are debug helpers, offering nothing else but assertions in case of problems.
3) I find the idea of removing code that "Violates policy" ludicrous. No one has the right to dermine if some piece of code violates policy or not, especially if the author writing it denies it. Only a judge or lawyer should be able to make that decision. Additionally, in this specific case, what could be done? The code is in SVN and even if rewritten it will 1) look the same, excpt "edx" would become "esi" and vice-versa 2) a judge would still argue that "hey, you had the previous code in SVN for over a year, you've all been tainted and could've just as easily looked at it". Furthermore, such attitude might start devolving into a dangerous witchhunt. Don't like someone's code? Report them and have it removed! This communist-era and fascist-era behaviour deeply scares me and reminds me of a country and regime which I fled. I do not want to see it happen, because it would slowly kill and rip apart this project.
These monthly Alex-bashings are starting to tire me very much and maybe it's time I took an offensive position instead of a defensive one. I do not want to start naming names, but many of our developers have already violated our policy in different ways. If you actively start enforcing it, then it will be my duty as an active developer to enforce it as well, meaning that hiding any information I have concerning other developers' violations would be considered as complicity, so I would be legally bound to report them. In other words, this would mean that the project would lose half of its developers.
I am sick of being treated as the black sheep and the "example". This stops here. I have always been put in the spotlight for almost any action I took, and I've always taken steps to repair it. But these public trials of guilt have passed a limit. Either start questionning everyone and treating every developer the same, or stop using me as a tool.
Best regards, Alex Ionescu
Steven Edwards wrote:
On 1/19/06, WaxDragon waxdragon@gmail.com wrote:
You are not a judge with years of experience in law. Whether or not you have any kernel internal knowledge is also irrelevant to this thought experiment.
No but I am someone trying to be objective that has spent a good part of the past few years reviewing case history for reverse engineering cases. Its more than we are going tot get from some judges.
Why did you have to do this? Is it not possible to write a driver that abuses fastcall to make a mostly working implementation without having to 1. look at and 2. copy the existing object code of Windows?
Alex clearly stated that there is only one way to perform that stack check, let's quote him properly:
"Note however, that there is only one way to check the stack: cmp ebp, esp. Unless you want to consider cmp esp, ebp as an alternate method."
As Casper said, it is legal to use that information, but not legal to *copy/paste* it into ReactOS. Alex clearly comprehends what that bit of assembly does.
Once again he may have stated this but he also states he disassembled Windows. The issue is the methods used to gather the information. Reverse engineering is legal if there is no other method to gather the information which is why I clearly asked "Was there no other way to get this information" or let me put it another way....
Alex: did you even bother doing some sort of clean room examination of Windows behavior based on third party drivers or some sort of testing or was IDA your first step? Checked Microsoft driver assertions and debug symbols don't count.
OK so someone else sneaked something in that violates the rules and it was not caught. Lets just check your argument for a moment and say you could be wrong about your development methods. Being ..."clearly commented, organized and structured..." does not amount to a hill of beans if I am violating the law and or project rules. I can make bank robbing plans that are "...clearly commented, organized and structured..." I don't think that will gain me much ground in court.
This analogy is invalid. The legality of this issue stems directly from whether or not he wrote the code. Robbing a bank is _always_ illegal, writing code is only illegal if you copy/paste it from a legitimate author, or implement a patented method.
No its perfectly a valid question. In law there is this concept called Mens Rea which means intent. Was his intent to create a independent unique work he himself created and he just needed the information for compatibly reasons or did he intend to just make it work without caring of the consequences to everyone else. Hence the question above. Was IDA the first step or the last?
Alex's structured and commented code demonstrates comprehension. In this case, where the code's function is clear, and constrained by implementation details, the code will be similar by anyone who implements it. Alex's comments and code structure shows that he understands what is going on in the assembly, and most likely shows that he wrote the code, as opposed to just copy/pasting existing code.
Just because he understands the code now is irrelevant. Its the method of which that understanding came. Because our work is going to be similar to windows the arguments about a derived work hangs upon the notion that we are independently creating our own implementation rather than looking at the original. We can read documentation about the original all day long, we can examine applications and drivers that use the original all day long but when we start to crack open the book of the original implementation we run the legal risk of being declared a derived work.
It only looks suspicious since you are not a kernel developer. Again, not something a judge would concern himself with. Now the prosecutor.....
/* Skip the other registers */ sub esp, 0x48
<snip>
ie. why 0x29C, why 0x48?
Since he is making room on the stack for another frame, this is a predefined size.
Hmm ok. So another size won't work? Where is it predefined? I ask not to accuse but to try to understand to be fair to all parties involved. But according to Hartmut this is a clear case of copy and paste. This is why we cannot allow this to continue. If dirty-room reverse engineering was the last resort then it would be a original implementation
further. Now, I do agree he could have used the safer "clean-room" method, but I'm not convinced that it would have yielded a significantly different implementation, and we might still be in the same position.
You admit that his implementation was not based on "clean-room". My question once again was why did it have to be dirty room? If there is no other option for making a compatible implementation then this discussion holds no water but if by your own words he could have used a safer method then there is a problem.
So we are back to the first question. What development methods were used. IDA first or last?
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Beautiful. I am happy. Alex, from what i have seen, i agree with the "black sheep" statement. I haven't seen a better msg on the list since this. Now that makes me feel that my work is done. I will continue to watch the project, but i feel to useless not working on it, and realy am not comfortable with the code (I am a *n*x clone kernel programer myself ). I plan to write an OS of my own soon ( "AHGG, Not another enama!!!" ) and may look for help. I will keep a link on my site up to reactos.org, but for now, until a day i am needed again...
brian friend of reactos my site: <psudobuddha's site> http://www.metawire.org/%7Epsudobuddha
On 1/19/06, Alex Ionescu ionucu@videotron.ca wrote:
Hi,
I'm going to answer generically, not point-by-point, since I don't have much time, but I hope I can cover everything:
- Those magic sizes were calculated in my head and I didn't have time
to make them into constants as I did many of them. 0x29C is the pre-defined value of NPX_FRAME_LENGTH + KTRAP_FRAME_LENGTH. 0x48 is the differerence in the KTRAP_FRAME between the registers that we will skip. I could've done (KTRAP_FRAME_XXX - KTRAP_FRAME_YYY).
- This is not a matter of driver compatibility. The fast system call
stub is a mostly hardware-defined entrypoint, handled by low-level software logic. In implementing it, there are only 3 available sources of information: Whatever minimal info the Intel manual gives, the Linux sources, the Windows kernel binary. It is almost simply impossible to "guess" how the stub should work. Filip tried to make it work more then a year ago, and even he gave up (the AMD version), beacuse it is simply too hard and confusing unless you have some available code to look at. As such, my first and foremost source was the Linux source code. It helped me understand how to setup the LSTAR MSR register, as well as the other register values. Then, through several mailing list posts, I was able to understand some bugs in the way ReactOS had its segments set up, which caused problems in the code. Then, to understand the way Windows chose between INT2E and SYSENTER, I found a document online written by a person called Elicz, which described the stub and what it should do, much in the same way people argued "clean-room reverse engineering" is done. With this information, I was able to write more then 85% of the stub. My next, and final remaining possible step, was to use IDA to look at the Windows code. I used it as a learning tool, not as a copying tool. It is hard to argue that what I did was "Reverse-engineering", which, to my knowledge, implies taking something apart to re-create it, since this usually implies converting the assembly code to functional C code or otherwise. But I don't view as looking at assembly in order to understand a low-level hardware interface as "reverse engineering". And yes, as described above, it -was- my last choice. Additionally, the parts which were supposedly "copied" are NOT part of the functional part of the code. They are debug helpers, offering nothing else but assertions in case of problems.
- I find the idea of removing code that "Violates policy" ludicrous. No
one has the right to dermine if some piece of code violates policy or not, especially if the author writing it denies it. Only a judge or lawyer should be able to make that decision. Additionally, in this specific case, what could be done? The code is in SVN and even if rewritten it will 1) look the same, excpt "edx" would become "esi" and vice-versa 2) a judge would still argue that "hey, you had the previous code in SVN for over a year, you've all been tainted and could've just as easily looked at it". Furthermore, such attitude might start devolving into a dangerous witchhunt. Don't like someone's code? Report them and have it removed! This communist-era and fascist-era behaviour deeply scares me and reminds me of a country and regime which I fled. I do not want to see it happen, because it would slowly kill and rip apart this project.
These monthly Alex-bashings are starting to tire me very much and maybe it's time I took an offensive position instead of a defensive one. I do not want to start naming names, but many of our developers have already violated our policy in different ways. If you actively start enforcing it, then it will be my duty as an active developer to enforce it as well, meaning that hiding any information I have concerning other developers' violations would be considered as complicity, so I would be legally bound to report them. In other words, this would mean that the project would lose half of its developers.
I am sick of being treated as the black sheep and the "example". This stops here. I have always been put in the spotlight for almost any action I took, and I've always taken steps to repair it. But these public trials of guilt have passed a limit. Either start questionning everyone and treating every developer the same, or stop using me as a tool.
Best regards, Alex Ionescu
Steven Edwards wrote:
On 1/19/06, WaxDragon waxdragon@gmail.com wrote:
You are not a judge with years of experience in law. Whether or not you have any kernel internal knowledge is also irrelevant to this thought experiment.
No but I am someone trying to be objective that has spent a good part of the past few years reviewing case history for reverse engineering cases. Its more than we are going tot get from some judges.
Why did you have to do this? Is it not possible to write a driver that abuses fastcall to make a mostly working implementation without having to 1. look at and 2. copy the existing object code of Windows?
Alex clearly stated that there is only one way to perform that stack check, let's quote him properly:
"Note however, that there is only one way to check the stack: cmp ebp, esp. Unless you want to consider cmp esp, ebp as an alternate method."
As Casper said, it is legal to use that information, but not legal to *copy/paste* it into ReactOS. Alex clearly comprehends what that bit of assembly does.
Once again he may have stated this but he also states he disassembled Windows. The issue is the methods used to gather the information. Reverse engineering is legal if there is no other method to gather the information which is why I clearly asked "Was there no other way to get this information" or let me put it another way....
Alex: did you even bother doing some sort of clean room examination of Windows behavior based on third party drivers or some sort of testing or was IDA your first step? Checked Microsoft driver assertions and debug symbols don't count.
OK so someone else sneaked something in that violates the rules and it was not caught. Lets just check your argument for a moment and say you could be wrong about your development methods. Being ..."clearly commented, organized and structured..." does not amount to a hill of beans if I am violating the law and or project rules. I can make bank robbing plans that are "...clearly commented, organized and structured..." I don't think that will gain me much ground in court.
This analogy is invalid. The legality of this issue stems directly from whether or not he wrote the code. Robbing a bank is _always_ illegal, writing code is only illegal if you copy/paste it from a legitimate author, or implement a patented method.
No its perfectly a valid question. In law there is this concept called Mens Rea which means intent. Was his intent to create a independent unique work he himself created and he just needed the information for compatibly reasons or did he intend to just make it work without caring of the consequences to everyone else. Hence the question above. Was IDA the first step or the last?
Alex's structured and commented code demonstrates comprehension. In this case, where the code's function is clear, and constrained by implementation details, the code will be similar by anyone who implements it. Alex's comments and code structure shows that he understands what is going on in the assembly, and most likely shows that he wrote the code, as opposed to just copy/pasting existing code.
Just because he understands the code now is irrelevant. Its the method of which that understanding came. Because our work is going to be similar to windows the arguments about a derived work hangs upon the notion that we are independently creating our own implementation rather than looking at the original. We can read documentation about the original all day long, we can examine applications and drivers that use the original all day long but when we start to crack open the book of the original implementation we run the legal risk of being declared a derived work.
It only looks suspicious since you are not a kernel developer. Again, not something a judge would concern himself with. Now the prosecutor.....
/* Skip the other registers */ sub esp, 0x48
<snip>
ie. why 0x29C, why 0x48?
Since he is making room on the stack for another frame, this is a predefined size.
Hmm ok. So another size won't work? Where is it predefined? I ask not to accuse but to try to understand to be fair to all parties involved. But according to Hartmut this is a clear case of copy and paste. This is why we cannot allow this to continue. If dirty-room reverse engineering was the last resort then it would be a original implementation
further. Now, I do agree he could have used the safer "clean-room" method, but I'm not convinced that it would have yielded a significantly different implementation, and we might still be in the same position.
You admit that his implementation was not based on "clean-room". My question once again was why did it have to be dirty room? If there is no other option for making a compatible implementation then this discussion holds no water but if by your own words he could have used a safer method then there is a problem.
So we are back to the first question. What development methods were used. IDA first or last?
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Might I remind you that, not withstanding someone hiring legal help to do this, the "opportunity" for someone such as a judge to determine legality of ROS's code would probably only occur only after ROS was in some pretty nasty legal trouble, which I think we'd all like to avoid.
What any individual dev "thinks" is honestly quite irrelevant. What matters is what a (potentially hostile) judge will think when presented with two near-identical pieces of code.
On 1/19/06, Brian briandabrain@gmail.com wrote:
Beautiful. I am happy. Alex, from what i have seen, i agree with the "black sheep" statement. I haven't seen a better msg on the list since this. Now that makes me feel that my work is done. I will continue to watch the project, but i feel to useless not working on it, and realy am not comfortable with the code (I am a *n*x clone kernel programer myself ). I plan to write an OS of my own soon ( "AHGG, Not another enama!!!" ) and may look for help. I will keep a link on my site up to reactos.org, but for now, until a day i am needed again...
brian friend of reactos my site: <psudobuddha's site> http://www.metawire.org/%7Epsudobuddha
On 1/19/06, Alex Ionescu ionucu@videotron.ca wrote:
Hi,
I'm going to answer generically, not point-by-point, since I don't have much time, but I hope I can cover everything:
- Those magic sizes were calculated in my head and I didn't have time
to make them into constants as I did many of them. 0x29C is the pre-defined value of NPX_FRAME_LENGTH + KTRAP_FRAME_LENGTH. 0x48 is the differerence in the KTRAP_FRAME between the registers that we will skip. I could've done (KTRAP_FRAME_XXX - KTRAP_FRAME_YYY).
- This is not a matter of driver compatibility. The fast system call
stub is a mostly hardware-defined entrypoint, handled by low-level software logic. In implementing it, there are only 3 available sources of information: Whatever minimal info the Intel manual gives, the Linux sources, the Windows kernel binary. It is almost simply impossible to "guess" how the stub should work. Filip tried to make it work more then a year ago, and even he gave up (the AMD version), beacuse it is simply too hard and confusing unless you have some available code to look at. As such, my first and foremost source was the Linux source code. It helped me understand how to setup the LSTAR MSR register, as well as the other register values. Then, through several mailing list posts, I was able to understand some bugs in the way ReactOS had its segments set up,
which caused problems in the code. Then, to understand the way Windows chose between INT2E and SYSENTER, I found a document online written by a person called Elicz, which described the stub and what it should do, much in the same way people argued "clean-room reverse engineering" is done. With this information, I was able to write more then 85% of the stub. My next, and final remaining possible step, was to use IDA to look
at the Windows code. I used it as a learning tool, not as a copying tool. It is hard to argue that what I did was "Reverse-engineering", which, to my knowledge, implies taking something apart to re-create it, since this usually implies converting the assembly code to functional C code or otherwise. But I don't view as looking at assembly in order to understand a low-level hardware interface as "reverse engineering". And yes, as described above, it -was- my last choice. Additionally, the parts which were supposedly "copied" are NOT part of the functional part of the code. They are debug helpers, offering nothing else but assertions in case of problems.
- I find the idea of removing code that "Violates policy" ludicrous. No
one has the right to dermine if some piece of code violates policy or not, especially if the author writing it denies it. Only a judge or lawyer should be able to make that decision. Additionally, in this specific case, what could be done? The code is in SVN and even if rewritten it will 1) look the same, excpt "edx" would become "esi" and vice-versa 2) a judge would still argue that "hey, you had the previous code in SVN for over a year, you've all been tainted and could've just as easily looked at it". Furthermore, such attitude might start devolving into a dangerous witchhunt. Don't like someone's code? Report them and have it removed! This communist-era and fascist-era behaviour deeply scares me and reminds me of a country and regime which I fled. I do not want to see it happen, because it would slowly kill and rip apart this project.
These monthly Alex-bashings are starting to tire me very much and maybe it's time I took an offensive position instead of a defensive one. I do not want to start naming names, but many of our developers have already violated our policy in different ways. If you actively start enforcing it, then it will be my duty as an active developer to enforce it as well, meaning that hiding any information I have concerning other developers' violations would be considered as complicity, so I would be legally bound to report them. In other words, this would mean that the project would lose half of its developers.
I am sick of being treated as the black sheep and the "example". This stops here. I have always been put in the spotlight for almost any action I took, and I've always taken steps to repair it. But these public trials of guilt have passed a limit. Either start questionning everyone and treating every developer the same, or stop using me as a tool.
Best regards, Alex Ionescu
Steven Edwards wrote:
On 1/19/06, WaxDragon waxdragon@gmail.com wrote:
You are not a judge with years of experience in law. Whether or not you have any kernel internal knowledge is also irrelevant to this thought experiment.
No but I am someone trying to be objective that has spent a good part of the past few years reviewing case history for reverse engineering cases. Its more than we are going tot get from some judges.
Why did you have to do this? Is it not possible to write a driver
that
abuses fastcall to make a mostly working implementation without
having
to 1. look at and 2. copy the existing object code of Windows?
Alex clearly stated that there is only one way to perform that stack check, let's quote him properly:
"Note however, that there is only one way to check the stack: cmp ebp,
esp. Unless you want to consider cmp esp, ebp as an alternate method."
As Casper said, it is legal to use that information, but not legal to *copy/paste* it into ReactOS. Alex clearly comprehends what that bit of assembly does.
Once again he may have stated this but he also states he disassembled Windows. The issue is the methods used to gather the information. Reverse engineering is legal if there is no other method to gather the information which is why I clearly asked "Was there no other way to get this information" or let me put it another way....
Alex: did you even bother doing some sort of clean room examination of Windows behavior based on third party drivers or some sort of testing or was IDA your first step? Checked Microsoft driver assertions and debug symbols don't count.
OK so someone else sneaked something in that violates the rules and
it
was not caught. Lets just check your argument for a moment and say
you
could be wrong about your development methods. Being ..."clearly commented, organized and structured..." does not amount to a hill of beans if I am violating the law and or project rules. I can make bank robbing plans that are "...clearly commented, organized and structured..." I don't think that will gain me much ground in court.
This analogy is invalid. The legality of this issue stems directly from whether or not he wrote the code. Robbing a bank is _always_ illegal, writing code is only illegal if you copy/paste it from a legitimate author, or implement a patented method.
No its perfectly a valid question. In law there is this concept called Mens Rea which means intent. Was his intent to create a independent unique work he himself created and he just needed the information for compatibly reasons or did he intend to just make it work without caring of the consequences to everyone else. Hence the question above. Was IDA the first step or the last?
Alex's structured and commented code demonstrates comprehension. In this case, where the code's function is clear, and constrained by implementation details, the code will be similar by anyone who implements it. Alex's comments and code structure shows that he understands what is going on in the assembly, and most likely shows that he wrote the code, as opposed to just copy/pasting existing code.
Just because he understands the code now is irrelevant. Its the method of which that understanding came. Because our work is going to be similar to windows the arguments about a derived work hangs upon the notion that we are independently creating our own implementation rather than looking at the original. We can read documentation about the original all day long, we can examine applications and drivers that use the original all day long but when we start to crack open the book of the original implementation we run the legal risk of being declared a derived work.
It only looks suspicious since you are not a kernel developer. Again, not something a judge would concern himself with. Now the prosecutor.....
/* Skip the other registers */ sub esp, 0x48
<snip>
ie. why 0x29C, why 0x48?
Since he is making room on the stack for another frame, this is a predefined size.
Hmm ok. So another size won't work? Where is it predefined? I ask not to accuse but to try to understand to be fair to all parties involved. But according to Hartmut this is a clear case of copy and paste. This is why we cannot allow this to continue. If dirty-room reverse engineering was the last resort then it would be a original implementation
further. Now, I do agree he could have used the safer "clean-room" method, but I'm not convinced that it would have yielded a significantly different implementation, and we might still be in the same position.
You admit that his implementation was not based on "clean-room". My question once again was why did it have to be dirty room? If there is no other option for making a compatible implementation then this discussion holds no water but if by your own words he could have used a safer method then there is a problem.
So we are back to the first question. What development methods were used. IDA first or last?
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi,
On 1/19/06, Alex Ionescu ionucu@videotron.ca wrote:
- Those magic sizes were calculated in my head and I didn't have time
- This is not a matter of driver compatibility. The fast system call
In regards to points 1 and 2 your explanation can be left up to the other developers to decide. When Hartmut, Filip, Art, and every other developer on irc/email says there is a problem I tend to believe them. I think the kernel developers should decide if there are violations and remove any cod that is found to be offending. I think that if it was all implemented in the methods you described then no, its not as bad a violation as its made out to be. However its still a issue.
- I find the idea of removing code that "Violates policy" ludicrous. No
one has the right to dermine if some piece of code violates policy or not, especially if the author writing it denies it. Only a judge or lawyer should be able to make that decision. Additionally, in this
I guess we never should have reverted Jon Wilsons patches that were copy/pasted from MSDN because they were just function prototypes and not real code. No the same rules apply. What point is there in having rules if we don't hold to them?
specific case, what could be done? The code is in SVN and even if rewritten it will 1) look the same, excpt "edx" would become "esi" and vice-versa 2) a judge would still argue that "hey, you had the previous code in SVN for over a year, you've all been tainted and could've just as easily looked at it". Furthermore, such attitude might start devolving into a dangerous witchhunt. Don't like someone's code? Report them and have it removed! This communist-era and fascist-era behaviour deeply scares me and reminds me of a country and regime which I fled. I do not want to see it happen, because it would slowly kill and rip apart this project.
At the risk of pissing off another developer, I have to say it. Your development methods and attitude have been doing that. Hartmut is leaving because of code he feels is tainted by the methods you use. Ge' spends less and less time working on ReactOS because he can't deal with your methods or behavior. Blight would not have been so pissed off about you breaking KDB if you had not fucked up the formatting at the same time you "fixed" it so he could have at least followed the code and tried to fix it or added a hack. He might not have even been so pissed off had you given a damn and helped him fix it.
These monthly Alex-bashings are starting to tire me very much and maybe it's time I took an offensive position instead of a defensive one. I do not want to start naming names, but many of our developers have already violated our policy in different ways. If you actively start enforcing it, then it will be my duty as an active developer to enforce it as well, meaning that hiding any information I have concerning other developers' violations would be considered as complicity, so I would be legally bound to report them. In other words, this would mean that the project would lose half of its developers.
Now lets get down to it. Lets say even if you have not violated the rules we agreed up and all of the developers are wrong about needing to revert some of your patches. I do not take well to threats. I do not appreciate it, nor does anyone else. I do not want to work with you any longer on this project. If you want to make threats, I suggest you take your ball and go play somewhere else.
I am sick of being treated as the black sheep and the "example". This stops here. I have always been put in the spotlight for almost any action I took, and I've always taken steps to repair it. But these public trials of guilt have passed a limit. Either start questionning everyone and treating every developer the same, or stop using me as a tool.
Stop doing things that drive developers away from this project. If you want to try and destroy this project out of some childish revenge then come out, make your accusations and be done with it, otherwise play by the rules.
I propose a vote on Hartmuts proposal depending on if he will stay with the project
Audit and rewrite code that is found to violate the IP Policy Doc [] Yes [] No
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Public allegations are being made and attitudes are flaring.
We are in dangerous legal ground in more than one area.
This discussion needs to be taken off-list and only those involved in the project ( commits and a few select others ) should be part of this discussion.
I repeat: DO NOT REPLY TO THIS THREAD ON THIS LIST ANY MORE.
On 1/19/06, Steven Edwards winehacker@gmail.com wrote:
Hi,
On 1/19/06, Alex Ionescu ionucu@videotron.ca wrote:
- Those magic sizes were calculated in my head and I didn't have time
- This is not a matter of driver compatibility. The fast system call
In regards to points 1 and 2 your explanation can be left up to the other developers to decide. When Hartmut, Filip, Art, and every other developer on irc/email says there is a problem I tend to believe them. I think the kernel developers should decide if there are violations and remove any cod that is found to be offending. I think that if it was all implemented in the methods you described then no, its not as bad a violation as its made out to be. However its still a issue.
- I find the idea of removing code that "Violates policy" ludicrous. No
one has the right to dermine if some piece of code violates policy or not, especially if the author writing it denies it. Only a judge or lawyer should be able to make that decision. Additionally, in this
I guess we never should have reverted Jon Wilsons patches that were copy/pasted from MSDN because they were just function prototypes and not real code. No the same rules apply. What point is there in having rules if we don't hold to them?
specific case, what could be done? The code is in SVN and even if rewritten it will 1) look the same, excpt "edx" would become "esi" and vice-versa 2) a judge would still argue that "hey, you had the previous code in SVN for over a year, you've all been tainted and could've just as easily looked at it". Furthermore, such attitude might start devolving into a dangerous witchhunt. Don't like someone's code? Report them and have it removed! This communist-era and fascist-era behaviour deeply scares me and reminds me of a country and regime which I fled. I do not want to see it happen, because it would slowly kill and rip apart this project.
At the risk of pissing off another developer, I have to say it. Your development methods and attitude have been doing that. Hartmut is leaving because of code he feels is tainted by the methods you use. Ge' spends less and less time working on ReactOS because he can't deal with your methods or behavior. Blight would not have been so pissed off about you breaking KDB if you had not fucked up the formatting at the same time you "fixed" it so he could have at least followed the code and tried to fix it or added a hack. He might not have even been so pissed off had you given a damn and helped him fix it.
These monthly Alex-bashings are starting to tire me very much and maybe it's time I took an offensive position instead of a defensive one. I do not want to start naming names, but many of our developers have already violated our policy in different ways. If you actively start enforcing it, then it will be my duty as an active developer to enforce it as well, meaning that hiding any information I have concerning other developers' violations would be considered as complicity, so I would be legally bound to report them. In other words, this would mean that the project would lose half of its developers.
Now lets get down to it. Lets say even if you have not violated the rules we agreed up and all of the developers are wrong about needing to revert some of your patches. I do not take well to threats. I do not appreciate it, nor does anyone else. I do not want to work with you any longer on this project. If you want to make threats, I suggest you take your ball and go play somewhere else.
I am sick of being treated as the black sheep and the "example". This stops here. I have always been put in the spotlight for almost any action I took, and I've always taken steps to repair it. But these public trials of guilt have passed a limit. Either start questionning everyone and treating every developer the same, or stop using me as a
tool.
Stop doing things that drive developers away from this project. If you want to try and destroy this project out of some childish revenge then come out, make your accusations and be done with it, otherwise play by the rules.
I propose a vote on Hartmuts proposal depending on if he will stay with the project
Audit and rewrite code that is found to violate the IP Policy Doc [X] Yes [] No
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Audit and rewrite!
I founded San Diego ROS Users Group. We are Alpha testing on Real hardware. If ROS becomes extinct we will become SD SkyOS UG.
-- David Johnson Voice Talent http://www.davefilms.us DaveFilms Digital Media - Audio [TM] Producer , Writer, Production Director/ Designer
Does this mean the ROS is going to die a violent death? No hope for a real alternative to M$ Windoze?
I am really looking forward to Version # 1.0.0 of ROS in both x86 and PPC.
People we (you devs) need to stick togather. Become a team! People are counting on YOU!
ROS-PPC + Open Workstation Computing platform. = Power to the People!
If you have to become 90% WinOS compatable then so be it! 90% is better than 0%
XP apps can be ported to ROS.
Maybe GvG and WD will come back if ROS went in this direction. Port Linux GNU code if you have to. Lets get a new GUI and a Integrated sound system. Use a open file system not FAT. Write a translator for FAT. -- David Johnson Voice Talent http://www.davefilms.us DaveFilms Digital Media - Audio [TM] Producer , Writer, Production Director/ Designer
On 1/19/06, David Johnson davidjohnson.johnson@gmail.com wrote:
On 1/19/06, Steven Edwards winehacker@gmail.com wrote:
Hi,
On 1/19/06, Alex Ionescu ionucu@videotron.ca wrote:
- Those magic sizes were calculated in my head and I didn't have time
- This is not a matter of driver compatibility. The fast system call
In regards to points 1 and 2 your explanation can be left up to the other developers to decide. When Hartmut, Filip, Art, and every other developer on irc/email says there is a problem I tend to believe them. I think the kernel developers should decide if there are violations and remove any cod that is found to be offending. I think that if it was all implemented in the methods you described then no, its not as bad a violation as its made out to be. However its still a issue.
- I find the idea of removing code that "Violates policy" ludicrous.
No
one has the right to dermine if some piece of code violates policy or not, especially if the author writing it denies it. Only a judge or lawyer should be able to make that decision. Additionally, in this
I guess we never should have reverted Jon Wilsons patches that were copy/pasted from MSDN because they were just function prototypes and not real code. No the same rules apply. What point is there in having rules if we don't hold to them?
specific case, what could be done? The code is in SVN and even if rewritten it will 1) look the same, excpt "edx" would become "esi" and vice-versa 2) a judge would still argue that "hey, you had the
previous
code in SVN for over a year, you've all been tainted and could've just as easily looked at it". Furthermore, such attitude might start devolving into a dangerous witchhunt. Don't like someone's code?
Report
them and have it removed! This communist-era and fascist-era behaviour deeply scares me and reminds me of a country and regime which I fled.
I
do not want to see it happen, because it would slowly kill and rip
apart
this project.
At the risk of pissing off another developer, I have to say it. Your development methods and attitude have been doing that. Hartmut is leaving because of code he feels is tainted by the methods you use. Ge' spends less and less time working on ReactOS because he can't deal with your methods or behavior. Blight would not have been so pissed off about you breaking KDB if you had not fucked up the formatting at the same time you "fixed" it so he could have at least followed the code and tried to fix it or added a hack. He might not have even been so pissed off had you given a damn and helped him fix it.
These monthly Alex-bashings are starting to tire me very much and
maybe
it's time I took an offensive position instead of a defensive one. I
do
not want to start naming names, but many of our developers have
already
violated our policy in different ways. If you actively start enforcing
it, then it will be my duty as an active developer to enforce it as well, meaning that hiding any information I have concerning other developers' violations would be considered as complicity, so I would
be
legally bound to report them. In other words, this would mean that the project would lose half of its developers.
Now lets get down to it. Lets say even if you have not violated the rules we agreed up and all of the developers are wrong about needing to revert some of your patches. I do not take well to threats. I do not appreciate it, nor does anyone else. I do not want to work with you any longer on this project. If you want to make threats, I suggest you take your ball and go play somewhere else.
I am sick of being treated as the black sheep and the "example". This stops here. I have always been put in the spotlight for almost any action I took, and I've always taken steps to repair it. But these public trials of guilt have passed a limit. Either start questionning everyone and treating every developer the same, or stop using me as a
tool.
Stop doing things that drive developers away from this project. If you want to try and destroy this project out of some childish revenge then come out, make your accusations and be done with it, otherwise play by the rules.
I propose a vote on Hartmuts proposal depending on if he will stay with the project
Audit and rewrite code that is found to violate the IP Policy Doc [X] Yes [] No
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Audit and rewrite!
I founded San Diego ROS Users Group. We are Alpha testing on Real hardware. If ROS becomes extinct we will become SD SkyOS UG.
-- David Johnson Voice Talent http://www.davefilms.us DaveFilms Digital Media - Audio [TM] Producer , Writer, Production Director/ Designer
-- David Johnson Voice Talent http://www.davefilms.us DaveFilms Digital Media - Audio [TM] Producer , Writer, Production Director/ Designer
Hi! Alex Ionescu wrote:
Hi,
I'm going to answer generically, not point-by-point, since I don't have much time, but I hope I can cover everything:
- Those magic sizes were calculated in my head and I didn't have time
to make them into constants as I did many of them. 0x29C is the pre-defined value of NPX_FRAME_LENGTH + KTRAP_FRAME_LENGTH. 0x48 is the differerence in the KTRAP_FRAME between the registers that we will skip. I could've done (KTRAP_FRAME_XXX - KTRAP_FRAME_YYY).
- This is not a matter of driver compatibility. The fast system call
stub is a mostly hardware-defined entrypoint, handled by low-level software logic. In implementing it, there are only 3 available sources of information: Whatever minimal info the Intel manual gives, the Linux sources, the Windows kernel binary. It is almost simply impossible to "guess" how the stub should work. Filip tried to make it work more then a year ago, and even he gave up (the AMD version), beacuse it is simply too hard and confusing unless you have some available code to look at. As such, my first and foremost source was the Linux source code. It helped me understand how to setup the LSTAR MSR register, as well as the other register values. Then, through several mailing list posts, I was able to understand some bugs in the way ReactOS had its segments set up, which caused problems in the code. Then, to understand the way Windows chose between INT2E and SYSENTER, I found a document online written by a person called Elicz, which described the stub and what it should do, much in the same way people argued "clean-room reverse engineering" is done. With this information, I was able to write more then 85% of the stub. My next, and final remaining possible step, was to use IDA to look at the Windows code. I used it as a learning tool, not as a copying tool. It is hard to argue that what I did was "Reverse-engineering", which, to my knowledge, implies taking something apart to re-create it, since this usually implies converting the assembly code to functional C code or otherwise. But I don't view as looking at assembly in order to understand a low-level hardware interface as "reverse engineering". And yes, as described above, it -was- my last choice. Additionally, the parts which were supposedly "copied" are NOT part of the functional part of the code. They are debug helpers, offering nothing else but assertions in case of problems.
- I find the idea of removing code that "Violates policy" ludicrous. No
one has the right to dermine if some piece of code violates policy or not, especially if the author writing it denies it. Only a judge or lawyer should be able to make that decision. Additionally, in this specific case, what could be done? The code is in SVN and even if rewritten it will 1) look the same, excpt "edx" would become "esi" and vice-versa 2) a judge would still argue that "hey, you had the previous code in SVN for over a year, you've all been tainted and could've just as easily looked at it". Furthermore, such attitude might start devolving into a dangerous witchhunt. Don't like someone's code? Report them and have it removed! This communist-era and fascist-era behaviour deeply scares me and reminds me of a country and regime which I fled. I do not want to see it happen, because it would slowly kill and rip apart this project.
I hear a duck, Does anyone else hear a duck. Wow I do!
These monthly Alex-bashings are starting to tire me very much and maybe it's time I took an offensive position instead of a defensive one. I do not want to start naming names, but many of our developers have already violated our policy in different ways. If you actively start enforcing it, then it will be my duty as an active developer to enforce it as well, meaning that hiding any information I have concerning other developers' violations would be considered as complicity, so I would be legally bound to report them. In other words, this would mean that the project would lose half of its developers.
I can start a formal investigation if you want?
I am sick of being treated as the black sheep and the "example". This stops here. I have always been put in the spotlight for almost any action I took, and I've always taken steps to repair it. But these public trials of guilt have passed a limit. Either start questionning everyone and treating every developer the same, or stop using me as a tool.
Best regards, Alex Ionescu
I would recommend everyone take a step back and think about this.
Please let us not wakeup that giant! (Not M$) James
Could you be a little more specific... The goals of reactOS developers don't necessarily match my goals but incorporating them at a later point is the option I have been waiting for. I really would like to do the J2SE implementation for ReactOS. I would also like to do an implementation of a Metadata filesystem, but it isn't time for that...
The goal is to create a working port of M$ Windows NT or whatever.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Hartmut Birr Sent: Tuesday, January 17, 2006 5:28 PM To: ReactOS Development List Subject: [ros-dev] Bye bye
Hi,
I'm leaving the ReactOS project. The goals of some developers don't match my goals.
Bye bye Hartmut _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Aleksey Bragin -
Alex Ionescu -
Brian -
Casper Hornstrup -
David Johnson -
Ge van Geldorp -
Hartmut Birr -
James Tabor -
Jason Filby -
Joseph Galbraith -
Kai Moonbourn -
Michael B. Trausch -
Rick Langschultz -
Royce Mitchell III -
Steven Edwards -
TwoTailedFox -
WaxDragon -
Wesley Parish