Undocumented APIs

[Casper Hornstrup]

I'd like to put this amendment to the IP policy to a vote, but first let's
start with the 7 day discussion period.

"If an API or a particular behaviour of an API which is part of the
Windows(R) operating system is not publicly documented by Microsoft, then
the API or the particular behaviour of the API may only be implemented in
ReactOS if there is documentation of published software which depend on the
API or the particular behaviour of the API, and which is not only
distributed with the Windows(R) operating system. The documentation must be
available in the repository."

I argue that the more ReactOS differ from Windows, the harder it will be to
prove that ReactOS is a derivative work of Windows.

Med venlig hilsen / best regards
Casper Hornstrup
Chief Executive Officer @ Eudicon
ch(a)eudicon.com / www.eudicon.com
([phone]

[Ge van Geldorp]

>   From: Casper Hornstrup
>  
>  I'd like to put this amendment to the IP policy to a vote, 
>  but first let's start with the 7 day discussion period.
>  
>  "If an API or a particular behaviour of an API which is part of the
>  Windows(R) operating system is not publicly documented by 
>  Microsoft, then the API or the particular behaviour of the 
>  API may only be implemented in ReactOS if there is 
>  documentation of published software which depend on the API 
>  or the particular behaviour of the API, and which is not only 
>  distributed with the Windows(R) operating system. The 
>  documentation must be available in the repository."
>  
>  I argue that the more ReactOS differ from Windows, the harder 
>  it will be to prove that ReactOS is a derivative work of Windows. 
In general, I agree with you, but I do have 2 remarks:

1) What about Internet Explorer? According to your proposal, we can't
implement an API if IE is the only app we find that depends on it.
Personally, I'd rather use Firefox anyway, but there is some stuff out there
that depends on IE.

2) Should this be limited to APIs or include undocumented data structures
too? An example I ran into last night: KPRCB. We know it's out there, some
of the fields are listed (e.g. by Probert) but I couldn't find any
"official" documentation.

GvG

[Thomas Weidenmueller]

Ge van Geldorp wrote:
>   2) Should this be limited to APIs or include
> undocumented data structures
>  too? An example I ran into last night: KPRCB. We know it's out there, some
>  of the fields are listed (e.g. by Probert) but I couldn't find any
>  "official" documentation. 
That's going to be a huge problem because there's not just the KPRCB. A
lot of structures are incompletely documented or not documented at all.
But they exist and most driver developers know that...

- Thomas

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of Thomas Weidenmueller
>  Sent: 31. januar 2006 11:50
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Undocumented APIs
>  
>  Ge van Geldorp wrote:
> >   2) Should this be limited to APIs or include
> > undocumented data 
>  structures
> >   too? An example I ran into last night: KPRCB. We
> > know it's out there, 
>  some
> >   of the fields are listed (e.g. by Probert) but I
> > couldn't find any
> >  "official" documentation. 
>  
>  That's going to be a huge problem because there's not just the KPRCB. A
>  lot of structures are incompletely documented or not documented at all.
>  But they exist and most driver developers know that... 
... so we should be able to find a driver that needs them.

Casper

[Magnus Olsen]

if we are not allown to use undoc struct or api
then this project is dead.
for example how ms open the directx hal interface and what value to put into
ntgdidd* to accpect the call is as well undoc. it was huge test and error
and ms directdraw driver interface are some part undoc by ms.
same with some gdi32 calls.

we must be allown to implement undoc api command and struct

I am not so good to type letters. I hope everyone understand what I mean



----- Original Message ----- 
From: "Thomas Weidenmueller" <w3seek(a)reactos.com>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: den 31 January 2006 11:50
Subject: Re: [ros-dev] Undocumented APIs


>   Ge van Geldorp wrote:
>  > 2) Should this be limited to APIs or include undocumented data 
structures
>   > too? An example I ran into last night: KPRCB. We
> know it's out there, 
some
> >   of the fields
> > are listed (e.g. by Probert) but I couldn't find any
> >  "official" documentation. 
>  That's going to be a huge problem because there's not just the KPRCB. A
>  lot of structures are incompletely documented or not documented at all.
>  But they exist and most driver developers know that...
>
>  - Thomas
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Casper Hornstrup]

DirectX is available at
http://www.microsoft.com/downloads/details.aspx?FamilyId=0A9B6820-BFBB-4799-
9908-D418CDEAC197&displaylang=en so this amendment wouldn't change anything
with respect to DirectX.

Casper

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of Magnus Olsen
>  Sent: 31. januar 2006 17:41
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Undocumented APIs
>  
>  if we are not allown to use undoc struct or api
>  then this project is dead.
>  for example how ms open the directx hal interface and what value to put
>  into
>  ntgdidd* to accpect the call is as well undoc. it was huge test and error
>  and ms directdraw driver interface are some part undoc by ms.
>  same with some gdi32 calls.
>  
>  we must be allown to implement undoc api command and struct
>  
>  I am not so good to type letters. I hope everyone understand what I mean

[Thomas Weidenmueller]

Casper Hornstrup wrote:
>   DirectX is available at
>  http://www.microsoft.com/downloads/details.aspx?FamilyId=0A9B6820-BFBB-4799-
>  9908-D418CDEAC197&displaylang=en so this amendment wouldn't change anything
>  with respect to DirectX. 
Except that some functions are documented incorrectly IIRC.

- Thomas

[Maarten Bosma]

Thomas Weidenmueller wrote:
>   Casper Hornstrup wrote:
>  
> >  DirectX is available at
> > http://www.microsoft.com/downloads/details.aspx?FamilyId=0A9B6820-BFBB-4799-
> > 9908-D418CDEAC197&displaylang=en so this amendment wouldn't change anything
> > with respect to DirectX. 
>  
>  
>  Except that some functions are documented incorrectly IIRC. 
Only the functionality not the prototypes and Casper wanted to say 
something different anyway: DirectX can be downloaded separately so we 
can implement all the functions and structs it relies on.

Maarten Bosma

[Magnus Olsen]

That is hard we are talking about lowlevel function
and how to open hal. and alot of other stuff

----- Original Message ----- 
From: "Maarten Bosma" <maarten.paul(a)bosma.de>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: den 31 January 2006 18:29
Subject: Re: [ros-dev] Undocumented APIs


>   Thomas Weidenmueller wrote:
> >   Casper Hornstrup wrote:
> >
> > >DirectX is available at 
> >http://www.microsoft.com/downloads/details.aspx?FamilyId=0A9B6820-BFBB-479 
9-
>   >>9908-D418CDEAC197&displaylang=en so this
> amendment wouldn't change 
anything
> > >  with respect to DirectX. 
> >
> >  Except that some functions are documented incorrectly IIRC. 
>  Only the functionality not the prototypes and Casper wanted to say
>  something different anyway: DirectX can be downloaded separately so we
>  can implement all the functions and structs it relies on.
>
>  Maarten Bosma
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of Thomas Weidenmueller
>  Sent: 31. januar 2006 18:21
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Undocumented APIs
>  
>  Casper Hornstrup wrote:
> >   DirectX is available at
> >  http://www.microsoft.com/downloads/details.aspx?FamilyId=0A9B6820-BFBB- 
>  4799-
> >   9908-D418CDEAC197&displaylang=en so this
> > amendment wouldn't change 
>  anything
> >   with respect to DirectX. 
>  
>  Except that some functions are documented incorrectly IIRC.
>  
>  - Thomas 
Hmm, please read the proposal for the amendment again. DirectX is not only
distributed with the Windows operating system, so if it requires an
undocumented API, then that API can be implemented in ReactOS (using
reverse engineering if needed) in order for ReactOS to be compatible with
DirectX.

Casper

[Magnus Olsen]

some driver sturct are not document in ddk or sdk or msdn u need read the
ddk drv code or access to 3d party driver source code. or reading alot
disambler code to  know how each member works.  and the doc in msdn/ddk/sdk
is compete wrong some time, the info is so bad I have trying figout
everthings how it  work (most basic stuff), thx thomas, filip, gvg and alex
that have keep me on right track how things work.

----- Original Message ----- 
From: "Thomas Weidenmueller" <w3seek(a)reactos.com>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: den 31 January 2006 18:21
Subject: Re: [ros-dev] Undocumented APIs


>   Casper Hornstrup wrote:
>  > DirectX is available at
>  > 
http://www.microsoft.com/downloads/details.aspx?FamilyId=0A9B6820-BFBB-4799-
>   > 9908-D418CDEAC197&displaylang=en so this
> amendment wouldn't change 
anything
> >   with respect
> > to DirectX. 
>  Except that some functions are documented incorrectly IIRC.
>
>  - Thomas
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Casper Hornstrup]

>   In general, I agree with you, but I do have 2
> remarks:
>  
>  1) What about Internet Explorer? According to your proposal, we can't
>  implement an API if IE is the only app we find that depends on it.
>  Personally, I'd rather use Firefox anyway, but there is some stuff out
>  there
>  that depends on IE. 
I worded it very carefully so software like IE isn't excluded. IE is not
only distributed with Windows. Regedit is however only distributed with
Windows.

>   2) Should this be limited to APIs or include
> undocumented data structures
>  too? An example I ran into last night: KPRCB. We know it's out there, some
>  of the fields are listed (e.g. by Probert) but I couldn't find any
>  "official" documentation.
>  
>  GvG 
I would be pro reformulating it to include structures and fields of
structures.

Casper

[Alex Ionescu]

Casper Hornstrup wrote:

>  I'd like to put this amendment to the IP policy to
> a vote, but first let's
> start with the 7 day discussion period.
>
> "If an API or a particular behaviour of an API which is part of the
> Windows(R) operating system is not publicly documented by Microsoft, then
> the API or the particular behaviour of the API may only be implemented in
> ReactOS if there is documentation of published software which depend on the
> API or the particular behaviour of the API, and which is not only
> distributed with the Windows(R) operating system. The documentation must be
> available in the repository."
>
> I argue that the more ReactOS differ from Windows, the harder it will be to
> prove that ReactOS is a derivative work of Windows.
>
> Med venlig hilsen / best regards
> Casper Hornstrup
> Chief Executive Officer @ Eudicon
> ch(a)eudicon.com / www.eudicon.com
> ([phone]
>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>   
>  
I am vehemently against this idea and I think it kills any chance of 
ReactOS being an NT clone. Have we changed goals or something? I thought 
the point wasn't just to run Windows applications.. if that's all we 
care about now, then why don't we just say fuck-all to the NT 
Architecture and you guys can go and do stuff your own way...get rid of 
smss, get rid of csrss, put win32k in usermode, don't use any internal 
NT structures anymore, and hell, don't even use syscalls anymore, nobody 
depends on those.

Best regards,
Alex Ionescu

[Steven Edwards]

Hi,

On 1/31/06, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   I am vehemently against this idea and I think it kills
> any chance of
>  ReactOS being an NT clone. Have we changed goals or something? I thought
>  the point wasn't just to run Windows applications.. if that's all we
>  care about now, then why don't we just say fuck-all to the NT
>  Architecture and you guys can go and do stuff your own way...get rid of
>  smss, get rid of csrss, put win32k in usermode, don't use any internal
>  NT structures anymore, and hell, don't even use syscalls anymore, nobody
>  depends on those. 
Linux is not a Unix clone, its a Unix replacement. There is no reason
we have to clone 100% of the Windows internal implementation. Its not
like our OpenGL.dll acts the same way internally as the Microsoft
OpenGL.dll but who cares it still works. When there is documentation
describing the way Windows does something then we should follow it.
When there is not documentation what choice do we have? If you are
going to reverse all of ntoskrnl.exe,csrss,win32k and friends for us
and publish a book based on its internals I have no doubt that the
project will use it as a reference.

--
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

[Alex Ionescu]

Steven Edwards wrote:

>  Hi,
>
> On 1/31/06, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   
>
> >  I am vehemently against this idea and I think it
> > kills any chance of
> > ReactOS being an NT clone. Have we changed goals or something? I thought
> > the point wasn't just to run Windows applications.. if that's all we
> > care about now, then why don't we just say fuck-all to the NT
> > Architecture and you guys can go and do stuff your own way...get rid of
> > smss, get rid of csrss, put win32k in usermode, don't use any internal
> > NT structures anymore, and hell, don't even use syscalls anymore, nobody
> > depends on those.
> >     
> >  
> Linux is not a Unix clone, its a Unix replacement. There is no reason
> we have to clone 100% of the Windows internal implementation. Its not
> like our OpenGL.dll acts the same way internally as the Microsoft
> OpenGL.dll but who cares it still works. When there is documentation
> describing the way Windows does something then we should follow it.
> When there is not documentation what choice do we have?
>   
>  
Well you're contradicting yourself..."When there is documentation 
describing the way Windows does something then we should follow it" then 
you say "If an API is not used by application then we should not 
implement it because it does not help the goal of the project". 
SMSS/CSRSS are documented and described in general...however not 
implementing them at all does not change the fact that Office and MSN 
Messenger will run. No application/driver depends on them...

You guys better decide, you seem kind of confused...are you going to 
create a working model of NT based on architectural information (and 
that includes, OSR, PDBs, MSDN, DDKs, NTDEV/NTIFS Mailing Lists, Windows 
Internals, Probert, etc) or are you going to create some half-assed OS 
that runs every app the users want?

Best regards,
Alex Ionescu

[WaxDragon]

>   You guys better decide, you seem kind of
> confused...are you going to
>  create a working model of NT based on architectural information (and
>  that includes, OSR, PDBs, MSDN, DDKs, NTDEV/NTIFS Mailing Lists, Windows
>  Internals, Probert, etc) or are you going to create some half-assed OS
>  that runs every app the users want? 
I think that's called Wine. ;0)

/me ducks
WD
--
<Alex_Ionescu> it's like saying let's rename Ke to Kernel because
people think it's Ketchup

[Steven Edwards]

On 1/31/06, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   Well you're contradicting yourself..."When
> there is documentation
>  describing the way Windows does something then we should follow it" then
>  you say "If an API is not used by application then we should not
>  implement it because it does not help the goal of the project".
>  SMSS/CSRSS are documented and described in general...however not
>  implementing them at all does not change the fact that Office and MSN
>  Messenger will run. No application/driver depends on them...
>
>  You guys better decide, you seem kind of confused...are you going to
>  create a working model of NT based on architectural information (and
>  that includes, OSR, PDBs, MSDN, DDKs, NTDEV/NTIFS Mailing Lists, Windows
>  Internals, Probert, etc) or are you going to create some half-assed OS
>  that runs every app the users want? 
It either must 1. Be documented or 2. Have a third party application
that depends on certain functionality. If MSDN, OSR, NTDEV Windows
Internels and Probert document it then sure we can implement it. I no
longer view the PDBs as a valid clean room source.

--
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

[Alex Ionescu]

Steven Edwards wrote:

>  On 1/31/06, Alex Ionescu <ionucu(a)videotron.ca>
> wrote:
>   
>
> >  Well you're contradicting
> > yourself..."When there is documentation
> > describing the way Windows does something then we should follow it" then
> > you say "If an API is not used by application then we should not
> > implement it because it does not help the goal of the project".
> > SMSS/CSRSS are documented and described in general...however not
> > implementing them at all does not change the fact that Office and MSN
> > Messenger will run. No application/driver depends on them...
> >
> > You guys better decide, you seem kind of confused...are you going to
> > create a working model of NT based on architectural information (and
> > that includes, OSR, PDBs, MSDN, DDKs, NTDEV/NTIFS Mailing Lists, Windows
> > Internals, Probert, etc) or are you going to create some half-assed OS
> > that runs every app the users want?
> >     
> >  
> It either must 1. Be documented or 2. Have a third party application
> that depends on certain functionality. If MSDN, OSR, NTDEV Windows
> Internels and Probert document it then sure we can implement it.
>  
You are still not being clear. Those sources document generic 
architecture, not direct APIs. If you implement it, then you need to 
implement undocumented APIs/entire modules which nobody will use.

>   I no
> longer view the PDBs as a valid clean room source.
>   
>  
I guess Microsoft won then, without even having to contact us. Will the 
DDK/IFS be considered dirty too, soon? You know, I've talked to some 
driver developers out there and people involved in NT kernel 
development, and they've been laughing out loud at this... good luck 
ever trying to achieve more then 0.1% driver support with this mentality.

>  --
> 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
>
>   
>  
Best regards,
Alex Ionescu

[James Tabor]

Alex Ionescu wrote:
>   Steven Edwards wrote:
>  
> >   On 1/31/06, Alex Ionescu
> > <ionucu(a)videotron.ca> wrote:
> >   
> >
> > >   Well you're contradicting
> > > yourself..."When there is documentation
> > >  describing the way Windows does something then we should follow it" then
> > >  you say "If an API is not used by application then we should not
> > >  implement it because it does not help the goal of the project".
> > >  SMSS/CSRSS are documented and described in general...however not
> > >  implementing them at all does not change the fact that Office and MSN
> > >  Messenger will run. No application/driver depends on them...
> > >
> > >  You guys better decide, you seem kind of confused...are you going to
> > >  create a working model of NT based on architectural information (and
> > >  that includes, OSR, PDBs, MSDN, DDKs, NTDEV/NTIFS Mailing Lists, Windows
> > >  Internals, Probert, etc) or are you going to create some half-assed OS
> > >  that runs every app the users want?
> > >     
> >
> >  It either must 1. Be documented or 2. Have a third party application
> >  that depends on certain functionality. If MSDN, OSR, NTDEV Windows
> >  Internels and Probert document it then sure we can implement it.
> >  
>  You are still not being clear. Those sources document generic 
>  architecture, not direct APIs. If you implement it, then you need to 
>  implement undocumented APIs/entire modules which nobody will use.
>  
> >   I no
> >  longer view the PDBs as a valid clean room source.
> >   
> >  
>  I guess Microsoft won then, without even having to contact us. Will the 
>  DDK/IFS be considered dirty too, soon? You know, I've talked to some 
>  driver developers out there and people involved in NT kernel 
>  development, and they've been laughing out loud at this... good luck 
>  ever trying to achieve more then 0.1% driver support with this mentality.
>   
I think that is what pissed tamlin off on the IRC! We can't look at anything
now because it's based on sdk/ddk and some book like "Undocumented Win 2k
Secrets"! It might be tainted? The book has documented structures that Alex
put into ntoskrnl and now gone! We have to start from scratch? WTF!

You can not look but you can touch, you can not touch but you can look?

Man! Sweden here we come!
James

[Steven Edwards]

On 1/31/06, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   I guess Microsoft won then, without even having to
> contact us. Will the
>  DDK/IFS be considered dirty too, soon? You know, I've talked to some
>  driver developers out there and people involved in NT kernel
>  development, and they've been laughing out loud at this... good luck
>  ever trying to achieve more then 0.1% driver support with this mentality. 
I am not saying ban the use of the pdb. I am saying use it in
conjunction with a third party driver. If you can't show me a driver
thats not working correctly then why do you need to look up the
information in the pdb?

--
Steven Edwards - ReactOS and Wine developer

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Steven Edwards]

Hi,

On 1/31/06, Steven Edwards <winehacker(a)gmail.com> wrote:
>   I am not saying ban the use of the pdb. I am saying
> use it in
>  conjunction with a third party driver. If you can't show me a driver
>  thats not working correctly then why do you need to look up the
>  information in the pdb? 
I would like to amend the vote proposal. A api or function can be
implemented if
1. Its documented, 2. A thirdparty driver or app depends on it.

Documented can include a PDB if used in conjunction with a test case.

--
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

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of Steven Edwards
>  Sent: 31. januar 2006 20:50
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Undocumented APIs
>  
>  Hi,
>  
>  On 1/31/06, Steven Edwards <winehacker(a)gmail.com> wrote:
> >   I am not saying ban the use of the pdb. I am
> > saying use it in
> >  conjunction with a third party driver. If you can't show me a driver
> >  thats not working correctly then why do you need to look up the
> >  information in the pdb? 
>  
>  I would like to amend the vote proposal. A api or function can be
>  implemented if
>  1. Its documented, 2. A thirdparty driver or app depends on it.
>
>  Documented can include a PDB if used in conjunction with a test case. 
This is what it already says. A driver is software.

Casper

[David Johnson]

Keep the NT 5+ compatibility.



On 1/31/06, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>  
>  Casper Hornstrup wrote:
>
> >  I'd like to put this amendment to the IP
> > policy to a vote, but first 
>  let's
> >  start with the 7 day discussion period.
> >
> > "If an API or a particular behaviour of an API which is part of the
> > Windows(R) operating system is not publicly documented by Microsoft, then
> > the API or the particular behaviour of the API may only be implemented in
> > ReactOS if there is documentation of published software which depend on 
>  the
> >  API or the particular behaviour of the API, and
> > which is not only
> > distributed with the Windows(R) operating system. The documentation must 
>  be
> >  available in the repository."
> >
> > I argue that the more ReactOS differ from Windows, the harder it will be 
>  to
> >  prove that ReactOS is a derivative work of
> > Windows.
> >
> > Med venlig hilsen / best regards
> > Casper Hornstrup
> > Chief Executive Officer @ Eudicon
> > ch(a)eudicon.com / www.eudicon.com
> > ([phone]
> >
> >
> >
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >  
>  I am vehemently against this idea and I think it kills any chance of
>  ReactOS being an NT clone. Have we changed goals or something? I thought
>  the point wasn't just to run Windows applications.. if that's all we
>  care about now, then why don't we just say fuck-all to the NT
>  Architecture and you guys can go and do stuff your own way...get rid of
>  smss, get rid of csrss, put win32k in usermode, don't use any internal
>  NT structures anymore, and hell, don't even use syscalls anymore, nobody
>  depends on those.
>
>  Best regards,
>  Alex Ionescu
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  


--
Dave Johnson
Voice Talent
Writer, Producer, Director

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of Alex Ionescu
>  Sent: 31. januar 2006 19:32
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Undocumented APIs
>  
>  I am vehemently against this idea and I think it kills any chance of
>  ReactOS being an NT clone. Have we changed goals or something? I thought
>  the point wasn't just to run Windows applications.. if that's all we
>  care about now, then why don't we just say fuck-all to the NT
>  Architecture and you guys can go and do stuff your own way...get rid of
>  smss, get rid of csrss, put win32k in usermode, don't use any internal
>  NT structures anymore, and hell, don't even use syscalls anymore, nobody
>  depends on those.
>  
>  Best regards,
>  Alex Ionescu 
Since when is ReactOS aiming to be a Windows clone?

Casper

[Alex Ionescu]

Casper Hornstrup wrote:

>    
>
> >  -----Original Message-----
> > From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
> > Behalf Of Alex Ionescu
> > Sent: 31. januar 2006 19:32
> > To: ReactOS Development List
> > Subject: Re: [ros-dev] Undocumented APIs
> >
> > I am vehemently against this idea and I think it kills any chance of
> > ReactOS being an NT clone. Have we changed goals or something? I thought
> > the point wasn't just to run Windows applications.. if that's all we
> > care about now, then why don't we just say fuck-all to the NT
> > Architecture and you guys can go and do stuff your own way...get rid of
> > smss, get rid of csrss, put win32k in usermode, don't use any internal
> > NT structures anymore, and hell, don't even use syscalls anymore, nobody
> > depends on those.
> >
> > Best regards,
> > Alex Ionescu
> >     
> >  
> Since when is ReactOS aiming to be a Windows clone?
>
> Casper
>   
>  
I'm sorry, that's the way Steven (and others) always called it at 
conferences/IRC channel.

Best regards,
Alex Ionescu

[David Hinz]

Alex Ionescu schrieb:
>   Casper Hornstrup wrote:
>  
> >    
> >  Since when is ReactOS aiming to be a Windows clone?
> >
> >  Casper
> >   
> >  
>  I'm sorry, that's the way Steven (and others) always called it at 
>  conferences/IRC channel. 
I personally also prefer this, as it is easier than saying
"ReactOS aims 
to be an OS that is binary compatible to Windows applications and 
drivers" and I think we are somewhere between these two things.
ReactOS is similar to Windows NT, but not a clone and shouldn't be one.

As Steven Edwards already said "Linux is not a Unix clone, its a Unix 
replacement" but most people say Linux is a UNIX clone, just because 
it's easier.
>   
>  Best regards,
>  Alex Ionescu 
Greets,

David Hinz

[Ged Murphy]

Alex Ionescu wrote:
>   I am vehemently against this idea and I think it kills
> any chance of 
>  ReactOS being an NT clone. Have we changed goals or something? I 
>  thought the point wasn't just to run Windows applications.. if that's 
>  all we care about now, then why don't we just say fuck-all to the NT 
>  Architecture and you guys can go and do stuff your own way...get rid 
>  of smss, get rid of csrss, put win32k in usermode, don't use any 
>  internal NT structures anymore, and hell, don't even use syscalls 
>  anymore, nobody depends on those. 
I want to see the end product as per the NT architecture. I thought this 
was always the goal.


>   You guys better decide, you seem kind of confused...
It seems that way to me too now.

>   are you going to create a working model of NT based
>  on architectural information (and that includes, OSR, PDBs, MSDN,  
DDKs,
NTDEV/NTIFS
>   Mailing Lists, Windows Internals, Probert, etc) or are
> you going to  
create some half-assed OS
>   that runs every app the users want? 
Hopefully the first. I would like to open Windows Internals and be able 
to work with ReactOS.
If attracting developers is an end goal, It makes sense that they are 
working with internals they are used to.
Granted the internal API's of a particular modual may be different, but 
the interfaces should be the same.

Ged.

[Steven Edwards]

Hi,

On 1/31/06, Ged Murphy <gedmurphy(a)gmail.com> wrote:
>   Hopefully the first. I would like to open Windows
> Internals and be able
>  to work with ReactOS.
>  If attracting developers is an end goal, It makes sense that they are
>  working with internals they are used to.
>  Granted the internal API's of a particular modual may be different, but
>  the interfaces should be the same. 
Like I explained to Alex on the channel. If you want to implement
something thats undocumented then you have to have someone document
it. If you want to implement AFD then have someone else reverse AFD
and publish the spec for it for you to follow. Its as simple as that.

Caspers proposal is very simple. For something to be implemented it must be:

1. Documented
2. Application or driver depends on it.

--
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

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of Ged Murphy
>  Sent: 31. januar 2006 20:54
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Undocumented APIs
>  
>  Alex Ionescu wrote:
> >   I am vehemently against this idea and I think it
> > kills any chance of
> >  ReactOS being an NT clone. Have we changed goals or something? I
> >  thought the point wasn't just to run Windows applications.. if that's
> >  all we care about now, then why don't we just say fuck-all to the NT
> >  Architecture and you guys can go and do stuff your own way...get rid
> >  of smss, get rid of csrss, put win32k in usermode, don't use any
> >  internal NT structures anymore, and hell, don't even use syscalls
> >  anymore, nobody depends on those. 
>  
>  I want to see the end product as per the NT architecture. I thought this
>  was always the goal. 
Architecture of which version of Windows?

Casper

[Andrew "Silver Blade" Greenwood]

As other people have commented, some applications may make use of 
undocumented API calls.

In a lot of cases the undocumented APIs may just be used internally, 
with no intention of 3rd-party software using them.

Whatever the case, it's worth documenting the undocumented APIs first of 
all, and leaving them unimplemented. Where they are necessary for the 
core components to function, we should substitute our own.

Then we wait for people to start filing bug reports saying application X 
doesn't run, and if it turns out a missing undocumented API function is 
needed, we implement it.

And/or we could stub the function calls and have them throw up an error 
message to indicate that an undocumented API is being used, and to tell 
the user to notify the devs or something.

But documentation is important in this case.

In summary:
1) Document all known undocumented APIs
2) Don't implement any of them (or, at most, stubs.)
3) Create an alternative for any undocumented API used internally
4) Only implement an undocumented API in the same way as Windows if 
third-party components depend on it.

[Magnus Olsen]

I against not implenet undoc api until apps need it. 
I think it need be implement as fast posible 
I know alot of manufactor using undoc api in there drivers
and it will be hel for us to found wish drv why it behoiver is like this

I agree with alex 

----- Original Message ----- 
From: "Andrew "Silver Blade" Greenwood"
<reactos(a)silverblade.co.uk>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: den 31 January 2006 20:12
Subject: Re: [ros-dev] Undocumented APIs


>   As other people have commented, some applications may
> make use of 
>  undocumented API calls.
>  
>  In a lot of cases the undocumented APIs may just be used internally, 
>  with no intention of 3rd-party software using them.
>  
>  Whatever the case, it's worth documenting the undocumented APIs first of 
>  all, and leaving them unimplemented. Where they are necessary for the 
>  core components to function, we should substitute our own.
>  
>  Then we wait for people to start filing bug reports saying application X 
>  doesn't run, and if it turns out a missing undocumented API function is 
>  needed, we implement it.
>  
>  And/or we could stub the function calls and have them throw up an error 
>  message to indicate that an undocumented API is being used, and to tell 
>  the user to notify the devs or something.
>  
>  But documentation is important in this case.
>  
>  In summary:
>  1) Document all known undocumented APIs
>  2) Don't implement any of them (or, at most, stubs.)
>  3) Create an alternative for any undocumented API used internally
>  4) Only implement an undocumented API in the same way as Windows if 
>  third-party components depend on it.
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Steven Edwards]

I want to draw this discussion to a close and vote. Here is my proposal.

A function can be implemented in ReactOS if:

1. There is documentation*
2. There exists a third party driver/application using the behavior

If such a document* or test case does not exist it must be documented
before it can be implemented. Clean room-reverse engineering rules
apply.

Documentation as defined as MSDN, OSR, DDK/PSDK example code, Probert
docs, Published Book, PDB with driver or dependant test, clean room
documentation written by some other developer than the one
implementing the function or any documentation found via a google, msn
or yahoo search. All documentation samples must be committed to SVN.

--
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

[James Tabor]

Steven Edwards wrote:
>   I want to draw this discussion to a close and vote.
> Here is my proposal.
>  
>  A function can be implemented in ReactOS if:
>  
>  1. There is documentation*
>  2. There exists a third party driver/application using the behavior
>  
>  If such a document* or test case does not exist it must be documented
>  before it can be implemented. Clean room-reverse engineering rules
>  apply.
>  
>  Documentation as defined as MSDN, OSR, DDK/PSDK example code, Probert
>  docs, Published Book, PDB with driver or dependant test, clean room
>  documentation written by some other developer than the one
>  implementing the function or any documentation found via a google, msn
>  or yahoo search. All documentation samples must be committed to SVN.
>   
This is fair for us here in the US. Laws here are strict and leave us with
little wiggle room.

One point:
Non US law ReactOS developers need to make their findings compatible to this
policy after it is voted in (or not?).

****
I must advise you developers, to use and follow your local laws! I can not make
you follow US law. I do not have a right to do so. Uphold your local laws!
****

Thanks,
James

[Samuel Bronson]

On Tue, 31 Jan 2006 18:40:57 -0500, Steven Edwards wrote:

>   Documentation as defined as MSDN, OSR, DDK/PSDK
> example code, Probert
>  docs, Published Book, PDB with driver or dependant test, clean room
>  documentation written by some other developer than the one implementing
>  the function or any documentation found via a google, msn or yahoo search.
>  All documentation samples must be committed to SVN. 
But that could violate the license! Or maybe you need to clarify here.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

[Magnus Olsen]

Then accoring  "2. There exists a third party driver/application using the
behavior" then we can  remove whole pnp, directx, win32k, rpc, network, usb
and more. alot of api is undoc or is wrong. WHat we have left no reactos
and I agesnt it. alot of manufactor using undoc api in lowlevel and u need
implement it right.  and I do not like we have vote on it. let us work on
how to implement stuff as we have always done.

other wise we can never achive
the goal
"ReactOS aims to achieve complete binary compatibility with both
applications and device drivers"



----- Original Message ----- 
From: "Steven Edwards" <winehacker(a)gmail.com>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: den 1 February 2006 00:40
Subject: Re: [ros-dev] Undocumented APIs


>   I want to draw this discussion to a close and vote.
> Here is my proposal.
>
>  A function can be implemented in ReactOS if:
>
>  1. There is documentation*
>  2. There exists a third party driver/application using the behavior
>
>  If such a document* or test case does not exist it must be documented
>  before it can be implemented. Clean room-reverse engineering rules
>  apply.
>
>  Documentation as defined as MSDN, OSR, DDK/PSDK example code, Probert
>  docs, Published Book, PDB with driver or dependant test, clean room
>  documentation written by some other developer than the one
>  implementing the function or any documentation found via a google, msn
>  or yahoo search. All documentation samples must be committed to SVN.
>
>  --
>  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

[Andrew "Silver Blade" Greenwood]

I don't see how we'd not have DirectX, PnP, USB, network etc. Software 
does depend on these things.

If an API is undocumented, or the documentation is wrong... As has been 
said time and time again, perform clean-room reverse engineering.

This doesn't necessarily apply to stuff we *need* essentially. You might 
want some obscure API implemented which is undocumented - all you'd need 
to do is make sure it was reversed *cleanly*.

Which requires the interest of at least 2 developers - one to reverse 
and document, the other to code.

If that's the general procedure we are to take, then **I don't see what 
the problem is**.



Magnus Olsen wrote:
>   Then accoring  "2. There exists a third party
> driver/application using the
>  behavior" then we can  remove whole pnp, directx, win32k, rpc, network, usb
>  and more. alot of api is undoc or is wrong. WHat we have left no reactos
>  and I agesnt it. alot of manufactor using undoc api in lowlevel and u need
>  implement it right.  and I do not like we have vote on it. let us work on
>  how to implement stuff as we have always done.
>  
>  other wise we can never achive
>  the goal
>  "ReactOS aims to achieve complete binary compatibility with both
>  applications and device drivers"

[mf]

Hi,

Andrew "Silver Blade" Greenwood wrote:
>   If that's the general procedure we are to take,
> then **I don't see what 
>  the problem is**. 
The problem is, that the developer that wants to implement the API needs 
to *prove* that there is some application/driver out there using it. As 
I said in the IRC channel yesterday, the fact that someone wants to 
invest his/her time into implementing it is reason enough to allow 
implementation. That doesn't mean the implementation shouldn't be 
clean-room. Following from that, Steven's proposition sounds a lot 
better than Casper's, and it is one I can agree with. If there is no 
documentation, make some, by having someone disassemble it and document 
his/her findings in a file outlining the API. This was the whole 
"working in pairs" thing we agreed upon in the meeting. Just to clarify 
slightly, this means nothing changes in our design goals or 
implementation, we just need to document what we disassemble, and the 
person doing the disassembling can't do the implementation. Simple as 
that. No other harm done.
So, imho all the folds are now ironed out of the proposition, and on to 
vote it is!

Cheers,
mf

[Nate DeSimone]

>    Following from that, Steven's proposition sounds
> a lot better than 
>  Casper's, and it is one I can agree with. If there is no 
>  documentation, make some, by having someone disassemble it and 
>  document his/her findings in a file outlining the API. This was the 
>  whole "working in pairs" thing we agreed upon in the meeting. 
I
personally think that worded that way, the amendment is redundant 
since it simply restates that you must to clean room reverse 
engineering.  All it amounts to is a clarification that the clean room 
approach must also be taken for undocumented APIs, so in effect what is 
the point of adding this in the first place?  The only reason to add 
this is to prevent misinterpretation of "clean room reverse engineer."

[Steven Edwards]

Hi Nate,

On 2/1/06, Nate DeSimone <desimn(a)rpi.edu> wrote:
>   I personally think that worded that way, the amendment
> is redundant
>  since it simply restates that you must to clean room reverse
>  engineering.  All it amounts to is a clarification that the clean room
>  approach must also be taken for undocumented APIs, so in effect what is
>  the point of adding this in the first place?  The only reason to add
>  this is to prevent misinterpretation of "clean room reverse engineer." 
I would like to agree on language and put it to the standard 7 day
vote. The emergency IRC meeting left some developers out due to time
constraints. I think we all agree on the clean room, one reverses the
other implements policy but I want to be sure we have the correct
language in place.

--
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

[mf]

Hiya,

Steven Edwards wrote:
>   I would like to agree on language and put it to the
> standard 7 day
>  vote. The emergency IRC meeting left some developers out due to time
>  constraints. I think we all agree on the clean room, one reverses the
>  other implements policy but I want to be sure we have the correct
>  language in place. 
After skyping with GreatLord (who still disagrees with the amendment as 
it is now) I would like to see "EITHER" clarified in the wording. You 
*either* supply documentation, *or* a test case. If you can't find 
documentation or a test case, you make said documentation or test case. 
In your current wording it could be misunderstood as "you need to supply 
documentation *and* a test case", which would simply be asking too much, 
at least imho. A lot of software use dirty tricks like direct binary 
addressing of private APIs (even for APIs that have perfectly functional 
public counterparts), for which finding test cases isn't realistic. 
Documenting all the addresses as obtained by disassembly and then having 
someone else implement it all, on the other hand, is realistic.

On another note, on #reactos-dev tamlin stated today:

17:37 <+tamlin> mf: I disagree that it is the problem. It is "only" one 
of many current problems as I see it. I also don't see it as all 
wrinkles as of yet having been ironed out.
18:47 <+tamlin> I came to think of something (I'm not suggesting this as 
workaround of anything, for anything): Does anyone really *know* what 
the legal status of "Trade Secret" (USA or other nations) is, if such 
information is publically available - whether the information, or even 
source code, has been acquired by legal or illegal means.
18:49 <+tamlin> I'm specifically thinking of Google, that I know at 
least in the past have made what's often referred to "proprietary, 
unpublished source code" available to anyone on the planet with a web 
browser and an internet connection.

Comments please.


mf

[James Tabor]

Hi!
Magnus Olsen wrote:
>   Then accoring  "2. There exists a third party
> driver/application using the
>  behavior" then we can  remove whole pnp, directx, win32k, rpc, network, usb
>  and more. alot of api is undoc or is wrong. WHat we have left no reactos
>  and I agesnt it. alot of manufactor using undoc api in lowlevel and u need
>  implement it right.  and I do not like we have vote on it. let us work on
>  how to implement stuff as we have always done.
>   
Wine is starting to fall into this trap too. If this policy goes into place
we will have to write up documents for these unknown apis and explain what
they do. Eventually we will publish M$ api for them w/o M$ giving it to the EU.

Well PnP, we have good source and 3rd party drivers using our interface to
install drivers from 3rd party vendors. The INF files are readable right?

Win32k, we can show and demonstrate the unknown apis with books and point to
locations in those books that those api functions do exist and we use them in
different ways.

The rest is the same. We have demonstrated with ReactOS that these unknown apis
exist and are used in one form or another with drivers and applications. We
have in our original source code to prove this even in a court. All we have to
do is document the apis. Yuck more work!

Get my point!

>   other wise we can never achive
>  the goal
>  "ReactOS aims to achieve complete binary compatibility with both
>  applications and device drivers" 
Yes we are loosing focus.
James

[Andrew "Silver Blade" Greenwood]

James Tabor wrote:
>   All we have to
>  do is document the apis. Yuck more work! 
What's wrong with that? Documentation will no doubt be of interest to 
anyone curious about the inner workings of NT - specifically the bits 
nobody else has revealed.

Even if we don't follow what NT does, it's worth documenting, both for 
our own sake and also in case anyone else is interested.

BUT, we would need to set out a standard way of formatting the 
documentation, I think.

[Robert Shearman]

James Tabor wrote:

>   Hi!
>  Magnus Olsen wrote:
>
> >   Then accoring  "2. There exists a third
> > party driver/application 
> >  using the
> >  behavior" then we can  remove whole pnp, directx, win32k, rpc, 
> >  network, usb
> >  and more. alot of api is undoc or is wrong. WHat we have left no reactos
> >  and I agesnt it. alot of manufactor using undoc api in lowlevel and u 
> >  need
> >  implement it right.  and I do not like we have vote on it. let us 
> >  work on
> >  how to implement stuff as we have always done.
> >  
>  Wine is starting to fall into this trap too. If this policy goes into 
>  place
>  we will have to write up documents for these unknown apis and explain 
>  what
>  they do. Eventually we will publish M$ api for them w/o M$ giving it 
>  to the EU. 

Why is this a bad thing? So, Wine has documentation for many functions 
(which is in some cases more comprehensive than MSDN). If a Wine 
developer comes along and uses the documentation and she now produces 
better code because she has better documentation to work from. If a 
Win32 developer comes along and uses the documentation then Wine gets 
free publicity.

The same argument applies for ReactOS.

-- 
Rob Shearman

[James Tabor]

Hi,
Casper Hornstrup wrote:
>   I'd like to put this amendment to the IP policy to
> a vote, but first let's
>  start with the 7 day discussion period.
>  
>  "If an API or a particular behaviour of an API which is part of the
>  Windows(R) operating system is not publicly documented by Microsoft, then
>  the API or the particular behaviour of the API may only be implemented in
>  ReactOS if there is documentation of published software which depend on the
>  API or the particular behaviour of the API, and which is not only
>  distributed with the Windows(R) operating system. The documentation must be
>  available in the repository."
>   
Some stuff is made up or guessed at.

>   I argue that the more ReactOS differ from Windows, the
> harder it will be to
>  prove that ReactOS is a derivative work of Windows.
>   
It is different, just some functions are compatible. That include structures too.
Let us not get confused about this. We need application to run on this. Drivers to
install, etc. If anyone want something other than this go to syllable.org.

So far this is issue DOA.

Thanks,
James

[mf]

Hi!

Casper Hornstrup wrote:
>   I'd like to put this amendment to the IP policy to
> a vote, but first let's
>  start with the 7 day discussion period.
>  
>  "If an API or a particular behaviour of an API which is part of the
>  Windows(R) operating system is not publicly documented by Microsoft, then
>  the API or the particular behaviour of the API may only be implemented in
>  ReactOS if there is documentation of published software which depend on the
>  API or the particular behaviour of the API, and which is not only
>  distributed with the Windows(R) operating system. The documentation must be
>  available in the repository." 
Too vague in my book. I request a reformulation. I sort of get what you 
try to indicate, but it's too easy to explain incorrectly and the 
meaning as I understand it doesn't include enough APIs to be of any 
significance to note down in the IP policy. There are also arguments 
against it, like the educational purpose of being able to lecture at 
universities on the subject of NT using ReactOS. In its current form, I 
would vote against the amendment.

mf