> Many internal data structures and internal functions, not exported anywhere and not part of the public symbols
I remember reading that even inside Microsoft, internal structures had to remain backwards-compatible because external, "very important" programs relied on them (violating the public API of course). I can't remember the source, unfortunately.
Now it would be interesting which aspects can affect compatibility and thus be part of a normal reverse engineering on the ReactOS side. For example, C usually does not remember structure names after compilation -- but "usually" is not always and depends on compilers, macros, and whatever somebody invented. The most interesting findings would of course be names that have absolutely no effect post-compilation AND were never published.
> If any of the presumed authors wants to chime in and explain the similitudes, I’m happy to change my mind, but be ready to answer some though questions about the origins your coding and naming styles, and all the design choices that you made and why you ended up architecting and writing things the way you say you did ;-)
On the internet, the burden of proof is on the accused.
"Many internal structures" that Axel believes are private and available only for MS employees, are actually published in the Internet, for example [1] [2]
I remember reading that even inside Microsoft, internal structures had to remain backwards-compatible because external, "very important" programs relied on them (violating the public API of course). I can't remember the source, unfortunately.
Now it would be interesting which aspects can affect compatibility and thus be part of a normal reverse engineering on the ReactOS side. For example, C usually does not remember structure names after compilation -- but "usually" is not always and depends on compilers, macros, and whatever somebody invented. The most interesting findings would of course be names that have absolutely no effect post-compilation AND were never published.
> If any of the presumed authors wants to chime in and explain the similitudes, I’m happy to change my mind, but be ready to answer some though questions about the origins your coding and naming styles, and all the design choices that you made and why you ended up architecting and writing things the way you say you did ;-)
On the internet, the burden of proof is on the accused.