17 Jan
2006
17 Jan
'06
11:28 p.m.
Hi,
I'm leaving the ReactOS project. The goals of some developers don't
match my goals.
Bye bye
Hartmut
17 Jan
17 Jan
11:36 p.m.
What sparked this?
On 1/17/06, Hartmut Birr <osexpert(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
"I had a handle on life, but then it broke"
18 Jan
18 Jan
12:11 a.m.
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
12:22 a.m.
Hi,
On 1/17/06, Hartmut Birr <osexpert(a)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
6:07 p.m.
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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
7:21 p.m.
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
8:01 p.m.
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
9:12 p.m.
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.
9:44 p.m.
Royce Mitchell III wrote:
Hartmut Birr wrote:
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
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.
10:06 p.m.
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(a)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:
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
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.
10:21 p.m.
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(a)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(a)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:
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
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.
10:26 p.m.
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
7:59 p.m.
Steven Edwards wrote:
Hi,
On 1/17/06, Hartmut Birr <osexpert(a)googlemail.com> wrote:
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
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
19 Jan
19 Jan
1:02 a.m.
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).
1:15 a.m.
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
6:28 a.m.
Hi,
Speaking as someone that is mostly ignorant of kernel internals, lets
pretend I am a judge....
On 1/18/06, Alex Ionescu <ionucu(a)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
2:47 p.m.
On 1/19/06, Steven Edwards <winehacker(a)gmail.com> wrote:
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.
It only looks suspicious since you are not a kernel developer. Again,
not something a judge would concern himself with. Now the
prosecutor.....
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(a)videotron.ca> 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."
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.
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?
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)
4:54 p.m.
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
5:31 p.m.
Hi Hartmut,
On 1/19/06, Hartmut Birr <osexpert(a)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:
1) 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.
2) Review all code
Agreed
3) 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
5:58 p.m.
Steven Edwards wrote:
Hi Hartmut,
On 1/19/06, Hartmut Birr <osexpert(a)googlemail.com> wrote:
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
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:
1) 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. 
20 Jan
20 Jan
4:32 a.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFD0GfEPXInbkqM7nwRAtUjAJ43rpD7uDAfSiTIOO7RhUJUv0imWgCeNF+2
anZZTZLi1w/dQabRD480+vE=
=ASOc
-----END PGP SIGNATURE-----
11:08 a.m.
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:
--
Clinersterton beademung, with all of love - RIP James Blish
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.
Hi Hartmut,
On 1/19/06, Hartmut Birr <osexpert(a)googlemail.com> wrote:
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev 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:
1) 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. 
19 Jan
19 Jan
5:50 p.m.
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
6:02 p.m.
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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
"I had a handle on life, but then it broke"
7:11 p.m.
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"
7:39 p.m.
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
20 Jan
20 Jan
11:05 a.m.
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
--
Clinersterton beademung, with all of love - RIP James Blish
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.
19 Jan
19 Jan
7:04 p.m.
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(a)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
20 Jan
20 Jan
4:24 a.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFD0GYCPXInbkqM7nwRAhpBAJ0ah6ax/r5+X9GDA8ZCNDf06JqfWgCeNV9h
/xCfZhFzkg0/gis6j9KNt/c=
=geK7
-----END PGP SIGNATURE-----
19 Jan
19 Jan
5:25 p.m.
On 1/19/06, WaxDragon <waxdragon(a)gmail.com> wrote:
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.
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?
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
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. 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.
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. 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
7:37 p.m.
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(a)gmail.com>
wrote:
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.
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?
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
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.
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.
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.
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
8 p.m.
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(a)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:
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(a)gmail.com>
wrote:
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.
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?
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
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
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.
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.
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.
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
8:33 p.m.
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(a)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(a)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:
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:
it
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
On 1/19/06, WaxDragon <waxdragon(a)gmail.com>
wrote:
that
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 >>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 >>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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
8:57 p.m.
Hi,
On 1/19/06, Alex Ionescu <ionucu(a)videotron.ca> wrote:
1) Those magic sizes were calculated in my head and I
didn't have time
2) 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.
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
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
9:24 p.m.
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.
9:50 p.m.
On 1/19/06, Steven Edwards <winehacker(a)gmail.com> wrote:
Hi,
On 1/19/06, Alex Ionescu <ionucu(a)videotron.ca> wrote:
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
1) Those magic sizes were calculated in my head
and I didn't have time
2) 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.
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
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
10:25 p.m.
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(a)gmail.com> wrote:
On 1/19/06, Steven Edwards <winehacker(a)gmail.com> wrote:
--
David Johnson
Voice Talent
http://www.davefilms.us
DaveFilms Digital Media - Audio [TM]
Producer , Writer,
Production Director/ Designer
Hi,
On 1/19/06, Alex Ionescu <ionucu(a)videotron.ca> wrote:
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
1) Those magic sizes were calculated in my head
and I didn't have time
2) 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.
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
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
20 Jan
20 Jan
12:12 a.m.
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:
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.
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
17 Jan
17 Jan
11:38 p.m.
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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
6817
days inactive
6820
days old
38 comments
18 participants
participants (18)
-
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