Re: [ros-kernel] Forward: "ReactOS is too limited"

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

At 13.03 03/06/2002, you wrote:
>so let's look into the gdi/user32-application case:
>   - provide a GDI which sends the stuff to network, probably as "simple"
>     as a video device driver providing it

this has been already done... sort of. See Sun's PCI Coprocessor: a PC 
squeezed to the size of a PCI card, plugged in a Sun computer. Sun provides 
drivers for Windows to use Solaris's X server as the coprocessor's display. 
Fullscreen only, of course

>   - provide it as a user32/gdi combo, allowing it to send information
>     about controls instead of line-by-line stuff.

I have gathered and/or thought of some ideas on this:
  - remote window stations, i.e. a process can be associated with the 
\\foo\windows\Winsta0 window station to receive input and display graphics 
using the devices of the machine foo. The window station is shared over 
NetBIOS, through an UNC provider
  - another useful addition could be the support for multiple interactive 
window stations, each associated with a different set of devices. IIRC, 
this isn't possible yet, because of limitations of the HID architecture
  - some parts of Windows aren't particularly "network friendly". The most 
important and most difficult is the clipboard, for obvious reasons. 
Luckily, "handles" returned by clipboard functions aren't directly usable 
as pointers, but must be "locked" first. This gives us a chance to copy the 
data across the network, if necessary (i.e. if the last copy/cut operation 
was made on the remote machine), an instant before it is used. Marshalling 
unknown clipboard formats is always possible, because the size of a 
clipboard memory object is always known. I haven't investigated OLE 
clipboard formats yet
  - another issue: in X11, IIRC, all windows are owned by the window 
manager. In Windows, instead, windows are owned by the threads that created 
them. This is easy to solve, but a bit expensive: mirror every thread 
owning windows on the machine that contains the display, or have a single 
thread serving all remote windows

There's more for sure, but this is what I can recall at the moment