reactos-kernel

RE: [ros-kernel] Some thoughts on the source tree and build system

[Robert C. <rob...@it...>]

> -----Original Message-----
> From: Eric Kohl [mailto:ek...@rz...]=20
> Sent: Saturday, April 27, 2002 4:24 AM

> >   - no separation of Win32 and native applications, libraries and
> services.
> > And they cannot be moved because of, again, CVS limitations=20
> (AFAIK).=20
> > What was the name of that other, better version system again?
>=20
> Agreed! I guess you mean 'arch'. Since you are complaining=20
> about CVS, would you volunteer as an arch-tester and try to=20
> find out whether it suits our needs?

Arch is quite neat... however here are some hints :}.

1) Use Jonathan Geislers parch, not larch. parch is perl based and for
win32 based systems will be... so much faster... it's not funny.
2) I'm working on a C++ port of arch, but that's still some distance
from being usable. When that's usable theres another volunteer who will
be making a WIN32 native port of arch.=20

Rob

RE: [ros-kernel] Possible licensing issues?

[Robert C. <rob...@it...>]

> -----Original Message-----
> From: KJK::Hyperion [mailto:no...@li...]=20
> Sent: Saturday, April 27, 2002 1:39 AM
> To: ReactOS-Kernel
> Subject: [ros-kernel] Possible licensing issues?
>=20
>=20
> A friend of mine has expressed a doubt about our choice of=20
> GPL as license.=20
> He says that there may be issues about running non-GPL stuff=20
> on system=20
> libraries that are entirely GPL. I somehow thought that GPL=20
> applied only to=20
> *interfacing* to a library, so only programs and drivers using=20
> ReactOS-specific functions or the implementation itself would=20
> fall under=20
> the "derivative works" category, but he told me that it isn't so, and=20
> suggested we ask the FSF for a definitive reply

The GPL -normally- covers everything, but it has an exception for system
libraries. What ReactOS needs to do is _grant_ an exception (which the
GPL also allows) stating that while the -content- of the headers etc is
GPL'd, linking to the them does -not- invoke the 'derivative work'
clauses.

Rob

[ros-kernel] CVS Commit: reactos

[Eric K. <ek...@rz...>]

Modified Files:
    apps/dump_shared_data/dump_shared_data.c
    include/napi/shared_data.h
    ntoskrnl/io/xhaldrv.c
    ntoskrnl/ke/main.c

Fixed drive map in the shared user page.


Eric

Re: [ros-kernel] Possible licensing issues?

[Eric K. <ek...@rz...>]

"KJK::Hyperion" <no...@li...> wrote:

> A friend of mine has expressed a doubt about our choice of GPL as license.
> He says that there may be issues about running non-GPL stuff on system
> libraries that are entirely GPL. I somehow thought that GPL applied only
to
> *interfacing* to a library, so only programs and drivers using
> ReactOS-specific functions or the implementation itself would fall under
> the "derivative works" category, but he told me that it isn't so, and
> suggested we ask the FSF for a definitive reply

The current licensing situation is definitely not okay! The main problem is
that the SDK/DDK headers and the import libraries are GPL'd too. This will
have to change. We will have to rerelease the headers and import libraries
and perhaps the .edf and .def files under the LGPL or entirely
non-copyrighted. This does not apply to internal header like
thentoskrnl/include/internal/*.h files. The documentation should be released
under GFDL and the other stuff remains under the GPL or its original
license.

> (personally, I think that the GPL is hysterical and I won't touch it with
a
> ten foot pole if I can choose to, and that this particular case is crazy,
> since basically every single part of ReactOS, down to the kernel, is some
> sort of DLL)

The current problem is not about dynamic linking to DLLs at runtime but
static linking of GPL'd import libraries to potentially non-GPL'd code.

> I'm surprised that this issue hasn't been addressed before, but maybe I
> don't remember, or I wasn't subscribed yet to the mailing lists. Comments?

I addressed this as part of the 'grand cleanup' some time ago. IIRC, the new
makefiles, the DK directory and the separated build of import libraries were
the result.


Eric

Re: [ros-kernel] Some thoughts on the source tree and build system

[Eric K. <ek...@rz...>]

"KJK::Hyperion" <no...@li...> wrote:

Hello, KJK::Hyperion!


> Hi all. I think it's time to review and/or fix our rather messy repository
> before it's too late and while the project is relatively inactive. Let's
> recap the known faults and kludges:

It is never too late. It is only getting more and more work to fix the
issues. ;-)

>   - a TON of duplicated code. We all know the hideous amount of identical
C
> runtime functions that MSVCRT, CRTDLL and NTDLL happily implement each by
> its own. MSVCRT and CRTDLL also have duplicated streams (stdio.h)
> libraries. NTDLL and NTOSKRNL contain two distinct duplicates of the RTL.
> In most of these cases even the compiled binary objects could be shared

IMO it is mostly a question of required disk space versus readability. I
don't like to move to another 'common' directory to have a look at a
function which is shared by multiple binaries.

Another point is the MSVCRT vs. CRTDLL and NTDLL vs. NTOSKRNL thingy. These
two pairs of binaries seem to share a lot of code but when you have a close
look at them, you will see that they are not the same! For example, MSVCRT
and CRTDLL seem to export the same functions. But they are *not* the same.
MSVCRT should be thread-safe and CRTDLL must not be thread-safe. The
situation is similar for NTDLL and NTOSKRNL. Have a very close look at the
Rtl-functions

>   - the build system isn't the best at handling dependencies.
Specifically:
>      - it doesn't always fully exploit the topological sorting implemented
> by make, but it requires in several cases to specify explicitely the build
> order of targets. An example is our master makefile
>      - inter-target dependencies have to be handled manually. This could
be
> solved with the monolithic makefile approach described in the paper
> "Recursive Make Considered Harmful", available at
> <http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html>

Agreed!

>   - empty, dead directories. I know this is because of limitations of CVS,

> but sure it's annoying

Agreed!

>   - no separation of Win32 and native applications, libraries and
services.
> And they cannot be moved because of, again, CVS limitations (AFAIK). What
> was the name of that other, better version system again?

Agreed! I guess you mean 'arch'. Since you are complaining about CVS, would
you volunteer as an arch-tester and try to find out whether it suits our
needs?

> That's not the whole story. I subscribed to the OSR ntdev mailing list,
and
> read the discussions of many real-world NT driver developers for months.
We
> don't want to alienate our possible future commercial partners, right?
> Here's what our tools and environment lack compared to those they're used
to:
>   - no clear separation of "debug" and "release" builds

Agreed!

>   - no support for the CodeView symbol format, only the "ancient" textual
> symbol lists

That's not a real issue because gcc can generate much better debugging
information. It's nm that extracts the 'ancient' .sym files.

>   - no BUILD utility. This means they have to maintain separatedly a
> makefile for ReactOS and DIRS/FILES files for the Microsoft DDK.

Is there any technical reason to switch to BUILD? IMO, using make is
sufficient because developers will not use the (not yet existing) ReactOS
DDK and the Microsoft DDK at the same time. The MS DDK is incomplete and no
longer freely available. The only advantage of the MS DDK is the
documentation. IMO, there is no reason to switch from the ReactOS DDK to the
MS DDK but a lot of reasons to switch to the ReactOS DDK. And MS will surely
no longer permit the use of the their DDK for 'evil GPL' drivers. ;-)

> Micromanagement is evil
>   - we mix source files with generated binaries. This is messy, and
> inflexible: how do you handle multiple different builds of some target?
for
> example "debug version for the i386 architecture, with Microsoft Windows
> compatibility options, statically linked", "release version for the SPARC
> architecture, with support for large files", and so on?

Agreed! Don't forget the Uniprocessor vs. Multiprocessor issue!

>   - while some could find cool having an integrated local kernel debugger
> (PICE), many more others would hate not being able to use WinDbg for
remote
> debugging
>
> I think I'm done now :-) Hope I didn't sound rude or something
> Comments?

No, you don't sound rude! At least as long as you volunteer for at least one
of the tasks. Otherwise I'll have to call you greedy. ;-)


Btw, could you consider using your real name on the ReactOS lists? I feel
like I'm talking to the pole of a streetlight. ;-)


Regards,
Eric Kohl

Re: [ros-kernel] Possible licensing issues?

[James T. <jim...@ad...>]

KJK::Hyperion wrote:
> 
> A friend of mine has expressed a doubt about our choice of GPL as license.
> He says that there may be issues about running non-GPL stuff on system
> libraries that are entirely GPL. I somehow thought that GPL applied only to
> *interfacing* to a library, so only programs and drivers using
> ReactOS-specific functions or the implementation itself would fall under
> the "derivative works" category, but he told me that it isn't so, and
> suggested we ask the FSF for a definitive reply
> 
> (personally, I think that the GPL is hysterical and I won't touch it with a
> ten foot pole if I can choose to, and that this particular case is crazy,
> since basically every single part of ReactOS, down to the kernel, is some
> sort of DLL)
> 
> I'm surprised that this issue hasn't been addressed before, but maybe I
> don't remember, or I wasn't subscribed yet to the mailing lists. Comments?
> 
Hi,
Wine is switching to LGPL theses days.
FYI,
James

Re: [ros-kernel] Possible licensing issues?

[Koert v. d. V. <ko...@ic...>]

Probably the LGPL ((lesser|library) gnu public licence) is more suitable for
the 'publicly linkable' libraries, and let everything that is run in
kernel-mode be GPL.

(read http://www.gnu.org/licenses/why-not-lgpl.html)

----- Original Message -----
> A friend of mine has expressed a doubt about our choice of GPL as license.
> He says that there may be issues about running non-GPL stuff on system
> libraries that are entirely GPL. I somehow thought that GPL applied only
to
> *interfacing* to a library, so only programs and drivers using
> ReactOS-specific functions or the implementation itself would fall under
> the "derivative works" category, but he told me that it isn't so, and
> suggested we ask the FSF for a definitive reply
>
> (personally, I think that the GPL is hysterical and I won't touch it with
a
> ten foot pole if I can choose to, and that this particular case is crazy,
> since basically every single part of ReactOS, down to the kernel, is some
> sort of DLL)
>
> I'm surprised that this issue hasn't been addressed before, but maybe I
> don't remember, or I wasn't subscribed yet to the mailing lists. Comments?
>
>
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

[ros-kernel] Possible licensing issues?

[KJK::Hyperion <no...@li...>]

A friend of mine has expressed a doubt about our choice of GPL as license. 
He says that there may be issues about running non-GPL stuff on system 
libraries that are entirely GPL. I somehow thought that GPL applied only to 
*interfacing* to a library, so only programs and drivers using 
ReactOS-specific functions or the implementation itself would fall under 
the "derivative works" category, but he told me that it isn't so, and 
suggested we ask the FSF for a definitive reply

(personally, I think that the GPL is hysterical and I won't touch it with a 
ten foot pole if I can choose to, and that this particular case is crazy, 
since basically every single part of ReactOS, down to the kernel, is some 
sort of DLL)

I'm surprised that this issue hasn't been addressed before, but maybe I 
don't remember, or I wasn't subscribed yet to the mailing lists. Comments?

[ros-kernel] Some thoughts on the source tree and build system

[KJK::Hyperion <no...@li...>]

Hi all. I think it's time to review and/or fix our rather messy repository 
before it's too late and while the project is relatively inactive. Let's 
recap the known faults and kludges:
  - a TON of duplicated code. We all know the hideous amount of identical C 
runtime functions that MSVCRT, CRTDLL and NTDLL happily implement each by 
its own. MSVCRT and CRTDLL also have duplicated streams (stdio.h) 
libraries. NTDLL and NTOSKRNL contain two distinct duplicates of the RTL. 
In most of these cases even the compiled binary objects could be shared
  - the build system isn't the best at handling dependencies. Specifically:
     - it doesn't always fully exploit the topological sorting implemented 
by make, but it requires in several cases to specify explicitely the build 
order of targets. An example is our master makefile
     - inter-target dependencies have to be handled manually. This could be 
solved with the monolithic makefile approach described in the paper 
"Recursive Make Considered Harmful", available at 
<http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html>
  - empty, dead directories. I know this is because of limitations of CVS, 
but sure it's annoying
  - no separation of Win32 and native applications, libraries and services. 
And they cannot be moved because of, again, CVS limitations (AFAIK). What 
was the name of that other, better version system again?

That's not the whole story. I subscribed to the OSR ntdev mailing list, and 
read the discussions of many real-world NT driver developers for months. We 
don't want to alienate our possible future commercial partners, right? 
Here's what our tools and environment lack compared to those they're used to:
  - no clear separation of "debug" and "release" builds
  - no support for the CodeView symbol format, only the "ancient" textual 
symbol lists
  - no BUILD utility. This means they have to maintain separatedly a 
makefile for ReactOS and DIRS/FILES files for the Microsoft DDK. 
Micromanagement is evil
  - we mix source files with generated binaries. This is messy, and 
inflexible: how do you handle multiple different builds of some target? for 
example "debug version for the i386 architecture, with Microsoft Windows 
compatibility options, statically linked", "release version for the SPARC 
architecture, with support for large files", and so on?
  - while some could find cool having an integrated local kernel debugger 
(PICE), many more others would hate not being able to use WinDbg for remote 
debugging

I think I'm done now :-) Hope I didn't sound rude or something
Comments?

[ros-kernel] CVS Commit: reactos

[Eric K. <ek...@rz...>]

Modified Files:
    apps/dump_shared_data/dump_shared_data.c
    include/ddk/ntddk.h
    include/napi/shared_data.h
    lib/kernel32/misc/dllmain.c
    lib/kernel32/misc/time.c
    lib/kernel32/file/volume.c
    lib/ntdll/ldr/startup.c
    lib/ntdll/ldr/utils.c
    lib/ntdll/rtl/misc.c
    ntoskrnl/ke/main.c
    ntoskrnl/ke/timer.c
    ntoskrnl/mm/mminit.c
    ntoskrnl/ps/process.c
    subsys/smss/init.c

Simplified access to the shared user page.
Update TickCountLow on timer ticks.


Eric

[ros-kernel] CVS Commit: freeldr

[Eric K. <ek...@rz...>]

Modified Files:
    freeldr/fs/iso.c

Removed direct debug output.
Replaced direct calls to bios routines.


Eric

[ros-kernel] CVS Commit: freeldr

[Eric K. <ek...@rz...>]

Modified files:
    bootsect/isoboot.asm

Added the original copyright from isolinux.
Added 'Press any key to boot from CD' feature.
Changed load path to '\REACTOS\FREELDR.SYS'.


Eric

[ros-kernel] CVS Commit: freeldr

[Brian P. <br...@sg...>]

Modified Files:
	FREELDR.INI notes.txt bootsect/Makefile freeldr/debug.c 
	freeldr/debug.h freeldr/freeldr.c freeldr/freeldr.h 
	freeldr/linux.c freeldr/linux.h freeldr/arch/i386/boot.S 
	freeldr/disk/disk.c freeldr/disk/partition.c freeldr/fs/fat.c 
	freeldr/fs/iso.c freeldr/mm/mm.c 
Removed Files:
	build.bat install.bat 

Log Message:

FreeLoader version 1.0!
Supports booting Linux bzImage kernels
No initrd support (yet)
No zImage support (yet)
No ext2 file system support (yet)
Forward slashes '/' as well as backslashes '\' can be used for path
names in FAT & ISO-9660
Fixed bug in LBA code where is was only reading one sector even if you
asked for more
Fixed bug in FAT code, was also present in ISO-9660 code

[ros-kernel] CVS Commit: reactos

[Eric K. <ek...@rz...>]

Modified files:
    services/storage/class2/class2.c

Implemented request-splitting.


Eric

[ros-kernel] reanimate ros-general

[Robert K. <ro...@ko...>]

Hi,
I want to reanimate the ros-general mailing list. I think
there are still many things to talk about.

So hurry up and subscribe there
http://lists.sourceforge.net/lists/listinfo/reactos-general

This is until we have a better alternative.

RE: [ros-kernel]ROS and Wine

[Steven E. <Ste...@ya...>]

> Yes, Steven has. Sometime ago Steven posted patches on the 
> wine list and as I can tell no one did anything with them. James

I understand why most of the patches were droped but no effort has been
made on the wine projects part to try and really work together. I am
very selective about how much time I am spending on wine untill our
windowing is working.

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

RE: [ros-kernel]RE: ROS and Wine

[Mark de W. <de...@a-...>]

> From: rea...@li...
> [mailto:rea...@li...]On Behalf Of Phillip
> Susi
>
> USER objects are shared between processes, within a desktop or window
> station I think.  GDI objects are (mostly) process specific.  I met a guy
> on irc a few weeks ago who is working on a really kickass program
> that digs
> through the user/gdi handle table and lets you view the objects such as
> bitmaps and whatnot.

An MSDN magazine article from some time last year did exactly this.  The
author supplied a framework for detecting GDI resource leaks, and the
viewing of GDI resources from the global GDI table (although I believe that
this latter feature only works on Win9x, as the win2k architecture deals
with GDI resources differently from win9x).

Mark

Re: [ros-kernel]ROS and Wine

[Jason F. <jas...@ya...>]

--- Casper Hornstrup <ch...@us...> wrote:

> tir, 2002-04-23 kl. 20:50 skrev Steven Edwards:
>>I've been working with them off and on for a while
>>also and they just seem to send any ideas to
>>/dev/null. The header issue with wine/mingw/reactos
>>was something Jason and I tried to really hit on at
>>wineconf. 
>That does not sound nice.

The header issue is actually quite important... but it doesn't add
any flashy functionality. However, I'm working on it when I have
time. I noticed that some files (like defines.h) have a notice that
they're automatically generated. I'm trying to contact the author
(Scott Christley) but so far the mails are bouncing.. trying to get
an email addy for him. Failing that I'm working on a database schema
for the include file contents and structure.

- Jason








__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

Re: [ros-kernel]ROS and Wine

[James T. <jim...@ad...>]

Hi,
Casper Hornstrup wrote:
> 
> tir, 2002-04-23 kl. 20:50 skrev Steven Edwards:
> > > We can use WINE modules that only use the Win32 API
> > > without any need to
> > > make changes specific to ReactOS. If we can agree
> > > with the WINE project
> > > to use the same headers, ReactOS developers can
> > > develop on the shared
> > > modules with less of a risk of breaking something
> > > for the WINE
> > > developers (and vice-versa).
> >
> > I've been working with them off and on for a while
> > also and they just seem to send any ideas to
> > /dev/null. The header issue with wine/mingw/reactos
> > was something Jason and I tried to really hit on at
> > wineconf.
> 
> That does not sound nice.
> 
> >
> > The only way we will be able to get them to really
> > jump on working hand in hand with us is if we get
> > NT/2K driver support because they want to try and port
> > it to linux. /me thinks what a ulgy fucking hack.
> >
> > Once we get our GUI kicking I think then we will have
> > some real pull with the WINE team and can then start
> > to work out a better intergration plan. Untill that
> > time dont expect much help from them.
> 
> Have you asked if they would accept patches that would make the headers
> more similar to w32api. What about the new x11 fork? Maybe they are more
> willing to cooporate?
> 

Yes, Steven has. Sometime ago Steven posted patches on the wine list and
as I can tell no one did anything with them.
James

[ros-kernel]RE: ROS and Wine

[Phillip S. <ps...@cf...>]

USER objects are shared between processes, within a desktop or window 
station I think.  GDI objects are (mostly) process specific.  I met a guy 
on irc a few weeks ago who is working on a really kickass program that digs 
through the user/gdi handle table and lets you view the objects such as 
bitmaps and whatnot.  I think the deal was that both types of handles come 
from a global handle table ( global to the desktop I think ) and the 
handles have an associated owning process id.  Global objects such as all 
user objects, and some gdi objects have an owning pid of 0, and thus are 
accessible from all processes.  The handle value itself is part index into 
the table, and part uniqueness value that is incremented every time the 
handle index is reused, to prevent accidental reuse of handles after the 
object has been deleted and the handle slot reused.  The objects also have 
parts that can exist in both paged pool, and the user address space of the 
owning process.  This allows user mode code to do things like 
GetWindowLong() w/o switching to kernel mode.

At 05:47 PM 4/23/2002 +0100, you wrote:
> > I'm working on it though I haven't actually done anything
> > since January. My
> > general approach was to rewrite code from WINE to work in
> > win32k.sys. What
> > advantage would be gained by moving to wineserver? I thought that all
> > USER objects were unique to a process.
>
>The wineserver stuff is just to make sure that the handles can be
>used between different processes.  The ROS win32k.sys code probably
>should use a handle table stored against the process desktop
>rather than the process itself (it might do this - I haven't
>looked extensively).
>
>The nice thing about using the Wine approach is that all the USER
>objects are allocated on the process heap so that you don't need
>to go to ring0 just to call GetWindowLong (which will obviously
>happen a lot).
>
>I was just thinking that porting Wine rather than reworking it would
>be a quicker (time wise) way to go.  I can see ways in which the
>win32k.sys could be more efficient.
>
>Mike.

Re: [ros-kernel]ROS and Wine

[Casper H. <ch...@us...>]

The missing reply-to is confusing...The reply-to-all function in outlook
will do the trick. Except that then the sender will get two copies, but
I can live with that. Many other mailing lists do this



tir, 2002-04-23 kl. 22:32 skrev Richard Campbell:
> Ok this is ever so offtopic, but basic driver support and basic message
> queue support should be one of the goals of the next version or the version
> afterwards anyways, well I'm outta my territory, back to mulling.
> 
> ----- Original Message -----
> From: "Casper Hornstrup" <ch...@us...>
> To: <rea...@li...>
> Sent: Tuesday, April 23, 2002 2:26 PM
> Subject: Re: [ros-kernel]ROS and Wine
> 
> 
> > tir, 2002-04-23 kl. 20:50 skrev Steven Edwards:
> > > > We can use WINE modules that only use the Win32 API
> > > > without any need to
> > > > make changes specific to ReactOS. If we can agree
> > > > with the WINE project
> > > > to use the same headers, ReactOS developers can
> > > > develop on the shared
> > > > modules with less of a risk of breaking something
> > > > for the WINE
> > > > developers (and vice-versa).
> > >
> > > I've been working with them off and on for a while
> > > also and they just seem to send any ideas to
> > > /dev/null. The header issue with wine/mingw/reactos
> > > was something Jason and I tried to really hit on at
> > > wineconf.
> >
> > That does not sound nice.
> >
> > >
> > > The only way we will be able to get them to really
> > > jump on working hand in hand with us is if we get
> > > NT/2K driver support because they want to try and port
> > > it to linux. /me thinks what a ulgy fucking hack.
> > >
> > > Once we get our GUI kicking I think then we will have
> > > some real pull with the WINE team and can then start
> > > to work out a better intergration plan. Untill that
> > > time dont expect much help from them.
> >
> > Have you asked if they would accept patches that would make the headers
> > more similar to w32api. What about the new x11 fork? Maybe they are more
> > willing to cooporate?
> >
> >
> >
> > _______________________________________________
> > reactos-kernel mailing list
> > rea...@li...
> > https://lists.sourceforge.net/lists/listinfo/reactos-kernel
> 
> 

Re: [ros-kernel]ROS and Wine

[Casper H. <ch...@us...>]

tir, 2002-04-23 kl. 20:50 skrev Steven Edwards:
> > We can use WINE modules that only use the Win32 API
> > without any need to
> > make changes specific to ReactOS. If we can agree
> > with the WINE project
> > to use the same headers, ReactOS developers can
> > develop on the shared
> > modules with less of a risk of breaking something
> > for the WINE
> > developers (and vice-versa).
> 
> I've been working with them off and on for a while
> also and they just seem to send any ideas to
> /dev/null. The header issue with wine/mingw/reactos
> was something Jason and I tried to really hit on at
> wineconf. 

That does not sound nice.

> 
> The only way we will be able to get them to really
> jump on working hand in hand with us is if we get
> NT/2K driver support because they want to try and port
> it to linux. /me thinks what a ulgy fucking hack. 
> 
> Once we get our GUI kicking I think then we will have
> some real pull with the WINE team and can then start
> to work out a better intergration plan. Untill that
> time dont expect much help from them.

Have you asked if they would accept patches that would make the headers
more similar to w32api. What about the new x11 fork? Maybe they are more
willing to cooporate?

Re: [ros-kernel]ROS and Wine

[Steven E. <ste...@ya...>]

> We can use WINE modules that only use the Win32 API
> without any need to
> make changes specific to ReactOS. If we can agree
> with the WINE project
> to use the same headers, ReactOS developers can
> develop on the shared
> modules with less of a risk of breaking something
> for the WINE
> developers (and vice-versa).

I've been working with them off and on for a while
also and they just seem to send any ideas to
/dev/null. The header issue with wine/mingw/reactos
was something Jason and I tried to really hit on at
wineconf. 

The only way we will be able to get them to really
jump on working hand in hand with us is if we get
NT/2K driver support because they want to try and port
it to linux. /me thinks what a ulgy fucking hack. 

Once we get our GUI kicking I think then we will have
some real pull with the WINE team and can then start
to work out a better intergration plan. Untill that
time dont expect much help from them.

Steven

__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

RE: [ros-kernel]ROS and Wine

[Casper H. <ch...@us...>]

tir, 2002-04-23 kl. 19:28 skrev Mike Shepherd:
> Yeah, I'd much rather duplicate what NT does but it just looked like
> a much bigger job.  Having looked at the code more extensively I can
> see that there's more there than I had thought.  Hopefully you
> appreciate that as a newbie poster it's useful to hear why design
> decisions made before my involvement were made!

Yes, we should be writing more docs about such issues ;o)

> 
> > > 
> > > Implementation ideas :-
> > > 
> > > 	- Remove the current user32.dll code and associated code in
> > > 	  win32k.sys etc. and replace with the relevant code from
> > > 	  Wine.
> > 
> > This is not just a copy/paste job, so why bother? Using WINE for
> > something as low-level as the window manager puts restrictions on the
> > design of the ReactOS window manager. If I had to choose, I would much
> > rather spend the time needed for adapting the WINE code for 
> > ReactOS, on
> > designing the window manager code properly - even if it takes longer.
> > Sure we can learn from the WINE implementation, but using its 
> > design is
> > IMO not worth it.
> 
> Fair enough.  I think the Wine USER code could be ported fairly quickly
> but I do agree that an NT like implementation would be more efficient
> and probably the longer term solution.

I guess that some of the WINE code that use GDI APIs (but not WINE
specific APIs) could be easily modified for ReactOS.

> 
> > We can use WINE modules that only use the Win32 API without 
> > any need to
> > make changes specific to ReactOS. If we can agree with the 
> > WINE project
> > to use the same headers, ReactOS developers can develop on the shared
> > modules with less of a risk of breaking something for the WINE
> > developers (and vice-versa).
> 
> Definitely.  It does look like things like comctl32.dll could be
> taken almost directly from Wine (assuming, as you say, uniform use
> of header files).

Yes, comctl32.dll is one of the many DLLs that can be written to
exclusively use the Win32 API.

RE: [ros-kernel]ROS and Wine

[Mike S. <Mi...@qf...>]

> > 	- The current (incomplete) user32.dll code calls
> > 	  into win32k.sys which then allocates ATOMs and
> > 	  Window structures in NonPagedPool (and are thus
> > 	  inaccessible from user mode).
> 
> An atom is just an integer which specifies an index into a 
> string table.
> So they are accessible from user-mode; that is, the ATOMs are, but the
> strings they represent are not. But then again, they don't need to
> because only win32k.sys uses the strings. ntdll.dll has a 
> user-mode atom
> implementation for user-mode applications.

My mistake.

> > 
> > 	- Wine uses a per-process user_handles array (global array
> > 	  above 200K???) and allocates all ATOMs and Windows
> > 	  on the local heap.  It allocates all handles via
> > 	  RPC-like calls to the wineserver via Unix domain sockets.
> > 
> > 	- Wine's implementation of most Window classes relies on
> > 	  dereferencing the Window structure allocated (using their
> > 	  WIN_GetPtr function)
> > 
> > 	- Message queue functions like PostMessage use RPC calls to
> > 	  wineserver to allow for handles from other processes.
> 
> WINE is different because it is mostly (fully?) implemented in
> user-mode. The ReactOS window manager implementation should be in
> kernel-mode to have better performance. The Windows NT team made this
> mistake - we don't have to. Also using RPC here sounds much more
> expensive than two kernel-mode/user-mode transitions. E.g. you have to
> marshal/unmarshal parameters.

Yeah, I'd much rather duplicate what NT does but it just looked like
a much bigger job.  Having looked at the code more extensively I can
see that there's more there than I had thought.  Hopefully you
appreciate that as a newbie poster it's useful to hear why design
decisions made before my involvement were made!

> > 
> > Implementation ideas :-
> > 
> > 	- Remove the current user32.dll code and associated code in
> > 	  win32k.sys etc. and replace with the relevant code from
> > 	  Wine.
> 
> This is not just a copy/paste job, so why bother? Using WINE for
> something as low-level as the window manager puts restrictions on the
> design of the ReactOS window manager. If I had to choose, I would much
> rather spend the time needed for adapting the WINE code for 
> ReactOS, on
> designing the window manager code properly - even if it takes longer.
> Sure we can learn from the WINE implementation, but using its 
> design is
> IMO not worth it.

Fair enough.  I think the Wine USER code could be ported fairly quickly
but I do agree that an NT like implementation would be more efficient
and probably the longer term solution.

> > 
> > 	- Implement the wineserver using LPC as an extension to 
> CSRSS.exe
> > 	  (or does this belong in WinLogon.exe?).  Obviously 
> only a small
> > 	  subset of the wineserver messages are needed (most are for
> > 	  synchronisation primitives that ROS implements anyway).
> 
> Who would communicate with the wineserver then? What is the point of
> having wineserver messages in ReactOS?

Just ease of porting.  I'm not claiming that it's a better solution.
I guess that, since I'm clearly not as comfortable with Kernel mode
issues as you (the networking code looks excellent BTW), I was trying
to find a way to turn it into a user mode solution!

> We can use WINE modules that only use the Win32 API without 
> any need to
> make changes specific to ReactOS. If we can agree with the 
> WINE project
> to use the same headers, ReactOS developers can develop on the shared
> modules with less of a risk of breaking something for the WINE
> developers (and vice-versa).

Definitely.  It does look like things like comctl32.dll could be
taken almost directly from Wine (assuming, as you say, uniform use
of header files).

> If we want to share lower-level user-mode modules we have to make the
> kernel-mode APIs the same, which would mean having equal
> ntdll/win32k.sys APIs. I'm not sure this is a good idea.

Agreed.  I was just talking about user32.dll code really.

> > 	- Presumably WinLogon or CSRSS need to do something 
> like creation
> > 	  of the Desktop and Desktop Window and monitor for Mouse and
> > 	  Keyboard events and translate into Windows messages.
> > 
> 
> In Windows NT, WinLogon creates the interactive windowstation and
> desktops. Win32k.sys connects to mouse and keyboard.

I've found that code now.  Didn't realise it was implemented.  Case of
RTFC!

> No, because this puts more load on the mailing list servers. A decent
> mail program has a reply-to-list funtion.

Fair enough.  Unfortunately I've got Outlook! :>)

Mike.