[Qemu-devel] Code Copy / New Linux boot code

[Qemu-devel] Code Copy / New Linux boot code

[Fabrice Bellard]

Just to give more information about the next commits:

1) I finally added a hand coded x86 to x86 translator. It means that 
qemu-fast has now close to native performances on x86. Who spoke about 
PC virtualization ? :-)

The x86 to x86 translator is limited to flat 32 bit mode and it does not 
support floating point (yet !). If the translator cannot handle a given 
instruction, then the "portable" translator is used as a fallback.

2) qemu-fast is being enhanced to run unpatched OSes and to support VESA 
VBE graphics.

The limitations of qemu-fast are that if data at addresses >= 0xc0000000 
is used, then soft MMU is used in the corresponding translated block.

Moreover, the guest user code has write access to the guest OS code and 
also to the host QEMU code. It means that qemu-fast is not safe. I don't 
know yet what is the best way to solve this issue.

3) A new and simpler Linux kernel loader has been added (for the 
'-kernel' command line option). Now the PC BIOS and the VGA BIOS are run 
before running the kernel, which gives exactly the same behavior as if 
the kernel was booted normally.

Fabrice.

Re: [Qemu-devel] Code Copy / New Linux boot code

[Grzegorz Kulewski]

Great!

On Mon, 16 Feb 2004, Fabrice Bellard wrote:
> 1) I finally added a hand coded x86 to x86 translator. It means that 
> qemu-fast has now close to native performances on x86. Who spoke about 
> PC virtualization ? :-)

What about qemu"-normal"? Will support for x86 -> x86 be added soon? Ever? 
Can it be added?

What about WinXP? Is installer working now? It still stops when formatting
discs?

What about Win98? (stability)
Can I use VESA modes in them? How to set that?

What about CD drive changing? I need that feature to install Win98 SE :)


Grzegorz Kulewski

Re: [Qemu-devel] Code Copy / New Linux boot code

[Fabrice Bellard]

Grzegorz Kulewski wrote:
> Great!
> 
> On Mon, 16 Feb 2004, Fabrice Bellard wrote:
> 
>>1) I finally added a hand coded x86 to x86 translator. It means that 
>>qemu-fast has now close to native performances on x86. Who spoke about 
>>PC virtualization ? :-)
> 
> 
> What about qemu"-normal"? Will support for x86 -> x86 be added soon? Ever? 
> Can it be added?

It can be made faster with a better code generator, but not that much. 
For best performances, I prefer to concentrate on allowing qemu-fast to 
run any OS.

> What about WinXP? Is installer working now? It still stops when formatting
> discs?

The installer works OK until the first reboot into graphical mode. Then 
there is a security error.

> What about Win98? (stability)

It is more stable in CVS, but there are still problems.

> Can I use VESA modes in them? How to set that?

You need a specific Windows driver (see the Bochs documentation). QEMU 
will have a better solution some day.

> What about CD drive changing? I need that feature to install Win98 SE :)

I will add it soon.

Fabrice.

Re: [Qemu-devel] Code Copy / New Linux boot code

[Jamie Burns]

Wow. Thanks for your hard work!

The x86 to x86 is just what I was hoping for - a fast case where host/target
CPU are the same architecture.

When I get some time, I plan to write some software for WindowsXP, so that
it will be able to export application windows in such a way that they can be
seen as "rootless" windows in a seperate windowing environment (on X11
etc.).

What this would mean for a virtual machine like Qemu is that Windows
applications could be run on Linux at near native speeds. Think of it like
Mac OSX's Classic environment - in this case, you load up Windows into the
virtual machine (you never have to actually show the Windows desktop per se)
and then launch applications which are exported to and framed by the X11
window manager. It should "feel" like Windows applications are running on
your Linux desktop at good speed with full compatability (as far as is
afforded by the virtual machine).

:o)

Jamie Burns.

----- Original Message ----- 
From: "Fabrice Bellard" <fabrice.bellard@free.fr>
To: <qemu-devel@nongnu.org>
Sent: Monday, February 16, 2004 12:07 AM
Subject: [Qemu-devel] Code Copy / New Linux boot code


> Just to give more information about the next commits:
>
> 1) I finally added a hand coded x86 to x86 translator. It means that
> qemu-fast has now close to native performances on x86. Who spoke about
> PC virtualization ? :-)
>
> The x86 to x86 translator is limited to flat 32 bit mode and it does not
> support floating point (yet !). If the translator cannot handle a given
> instruction, then the "portable" translator is used as a fallback.
>
> 2) qemu-fast is being enhanced to run unpatched OSes and to support VESA
> VBE graphics.
>
> The limitations of qemu-fast are that if data at addresses >= 0xc0000000
> is used, then soft MMU is used in the corresponding translated block.
>
> Moreover, the guest user code has write access to the guest OS code and
> also to the host QEMU code. It means that qemu-fast is not safe. I don't
> know yet what is the best way to solve this issue.
>
> 3) A new and simpler Linux kernel loader has been added (for the
> '-kernel' command line option). Now the PC BIOS and the VGA BIOS are run
> before running the kernel, which gives exactly the same behavior as if
> the kernel was booted normally.
>
> Fabrice.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Code Copy / New Linux boot code

[Ed Suominen]

Jamie, your rootless windows concept, in conjunction with QEMU's
emerging ability to provide VMware-like virtualization in a GPL package,
could be an excellent way to make existing Windows speech recognition
software seamlessly usable on the linux desktop. If it's not too much
trouble, please keep me apprised of your progress in this area!

Best regards,
Ed Suominen

Copy to mailing list of the
Open Source Speech Recognition Initiative

Link: QEMU (http://fabrice.bellard.free.fr/qemu/)

On Mon, 16 Feb 2004 00:52:56 -0000
"Jamie Burns" <jamie.burns@dynamicexpression.co.uk> wrote:

> Wow. Thanks for your hard work!
> 
> The x86 to x86 is just what I was hoping for - a fast case where
> host/target CPU are the same architecture.
> 
> When I get some time, I plan to write some software for WindowsXP, so
> that it will be able to export application windows in such a way that
> they can be seen as "rootless" windows in a seperate windowing
> environment (on X11 etc.).
> 
> What this would mean for a virtual machine like Qemu is that Windows
> applications could be run on Linux at near native speeds. Think of it
> like Mac OSX's Classic environment - in this case, you load up Windows
> into the virtual machine (you never have to actually show the Windows
> desktop per se) and then launch applications which are exported to and
> framed by the X11 window manager. It should "feel" like Windows
> applications are running on your Linux desktop at good speed with full
> compatability (as far as is afforded by the virtual machine).
> 
> :o)
> 
> Jamie Burns.
> 
> ----- Original Message ----- 
> From: "Fabrice Bellard" <fabrice.bellard@free.fr>
> To: <qemu-devel@nongnu.org>
> Sent: Monday, February 16, 2004 12:07 AM
> Subject: [Qemu-devel] Code Copy / New Linux boot code
> 
> 
> > Just to give more information about the next commits:
> >
> > 1) I finally added a hand coded x86 to x86 translator. It means that
> > qemu-fast has now close to native performances on x86. Who spoke
> > about PC virtualization ? :-)
> >
> > The x86 to x86 translator is limited to flat 32 bit mode and it does
> > not support floating point (yet !). If the translator cannot handle
> > a given instruction, then the "portable" translator is used as a
> > fallback.
> >
> > 2) qemu-fast is being enhanced to run unpatched OSes and to support
> > VESA VBE graphics.
> >
> > The limitations of qemu-fast are that if data at addresses >=
> > 0xc0000000 is used, then soft MMU is used in the corresponding
> > translated block.
> >
> > Moreover, the guest user code has write access to the guest OS code
> > and also to the host QEMU code. It means that qemu-fast is not safe.
> > I don't know yet what is the best way to solve this issue.
> >
> > 3) A new and simpler Linux kernel loader has been added (for the
> > '-kernel' command line option). Now the PC BIOS and the VGA BIOS are
> > run before running the kernel, which gives exactly the same behavior
> > as if the kernel was booted normally.
> >
> > Fabrice.
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Code Copy / New Linux boot code

[Michael Torrie]

On Sun, 2004-02-15 at 20:43, Ed Suominen wrote:
> Jamie, your rootless windows concept, in conjunction with QEMU's
> emerging ability to provide VMware-like virtualization in a GPL package,
> could be an excellent way to make existing Windows speech recognition
> software seamlessly usable on the linux desktop. If it's not too much
> trouble, please keep me apprised of your progress in this area!

Seems like the best approach would be to write a special graphics driver
for MS Windows that would translate gdi calls into X calls, allowing
Windows windows to be displayed on the X desktop, with the Windows
desktop hidden.  Eventually things like the system tray could be thunked
to display icons in the Gnome/KDE tray area.  All in all, I think such a
thing would be incredibly useful.

Michael


> 
> Best regards,
> Ed Suominen
> 
> Copy to mailing list of the
> Open Source Speech Recognition Initiative
> 
> Link: QEMU (http://fabrice.bellard.free.fr/qemu/)
> 
> On Mon, 16 Feb 2004 00:52:56 -0000
> "Jamie Burns" <jamie.burns@dynamicexpression.co.uk> wrote:
> 
> > Wow. Thanks for your hard work!
> > 
> > The x86 to x86 is just what I was hoping for - a fast case where
> > host/target CPU are the same architecture.
> > 
> > When I get some time, I plan to write some software for WindowsXP, so
> > that it will be able to export application windows in such a way that
> > they can be seen as "rootless" windows in a seperate windowing
> > environment (on X11 etc.).
> > 
> > What this would mean for a virtual machine like Qemu is that Windows
> > applications could be run on Linux at near native speeds. Think of it
> > like Mac OSX's Classic environment - in this case, you load up Windows
> > into the virtual machine (you never have to actually show the Windows
> > desktop per se) and then launch applications which are exported to and
> > framed by the X11 window manager. It should "feel" like Windows
> > applications are running on your Linux desktop at good speed with full
> > compatability (as far as is afforded by the virtual machine).
> > 
> > :o)
> > 
> > Jamie Burns.
> > 
> > ----- Original Message ----- 
> > From: "Fabrice Bellard" <fabrice.bellard@free.fr>
> > To: <qemu-devel@nongnu.org>
> > Sent: Monday, February 16, 2004 12:07 AM
> > Subject: [Qemu-devel] Code Copy / New Linux boot code
> > 
> > 
> > > Just to give more information about the next commits:
> > >
> > > 1) I finally added a hand coded x86 to x86 translator. It means that
> > > qemu-fast has now close to native performances on x86. Who spoke
> > > about PC virtualization ? :-)
> > >
> > > The x86 to x86 translator is limited to flat 32 bit mode and it does
> > > not support floating point (yet !). If the translator cannot handle
> > > a given instruction, then the "portable" translator is used as a
> > > fallback.
> > >
> > > 2) qemu-fast is being enhanced to run unpatched OSes and to support
> > > VESA VBE graphics.
> > >
> > > The limitations of qemu-fast are that if data at addresses >=
> > > 0xc0000000 is used, then soft MMU is used in the corresponding
> > > translated block.
> > >
> > > Moreover, the guest user code has write access to the guest OS code
> > > and also to the host QEMU code. It means that qemu-fast is not safe.
> > > I don't know yet what is the best way to solve this issue.
> > >
> > > 3) A new and simpler Linux kernel loader has been added (for the
> > > '-kernel' command line option). Now the PC BIOS and the VGA BIOS are
> > > run before running the kernel, which gives exactly the same behavior
> > > as if the kernel was booted normally.
> > >
> > > Fabrice.
> > >
> > >
> > >
> > > _______________________________________________
> > > Qemu-devel mailing list
> > > Qemu-devel@nongnu.org
> > > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > 
> > 
> > 
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
-- 
Michael Torrie <torriem@chem.byu.edu>

Re: [Qemu-devel] Code Copy / New Linux boot code

[Lionel Ulmer]

> Seems like the best approach would be to write a special graphics driver
> for MS Windows that would translate gdi calls into X calls, allowing
> Windows windows to be displayed on the X desktop, with the Windows
> desktop hidden.  Eventually things like the system tray could be thunked
> to display icons in the Gnome/KDE tray area.  All in all, I think such a
> thing would be incredibly useful.

Well, this already exists : it's called Wine :-)

                  Lionel
-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Code Copy / New Linux boot code

[Michael Torrie]

On Mon, 2004-02-16 at 05:33, Lionel Ulmer wrote:
> > Seems like the best approach would be to write a special graphics driver
> > for MS Windows that would translate gdi calls into X calls, allowing
> > Windows windows to be displayed on the X desktop, with the Windows
> > desktop hidden.  Eventually things like the system tray could be thunked
> > to display icons in the Gnome/KDE tray area.  All in all, I think such a
> > thing would be incredibly useful.
> 
> Well, this already exists : it's called Wine :-)

No, Wine is an attempt to implement the Windows API on linux.  What I've
described has nothing to do with that.  Instead, you run Windows XP (the
real version) inside of the qemu virtual  machine.  Then the special
graphics driver pushes each window out to X11 (probably using the
network, since that would require no changes to qemu).  Then if you hide
the main qemu window, you have a full, rootless Windows XP system
running on top of your linux machine.  Since it's the real deal, there
are no compatibility problems like you have with wine.  In many places,
this type of functionality would be very much appreciated and used as
people transition to Linux.

Michael


> 
>                   Lionel
-- 
Michael Torrie <torriem@chem.byu.edu>

Re: [Qemu-devel] Code Copy / New Linux boot code

[Rutger Nijlunsing]

On Mon, Feb 16, 2004 at 11:02:14AM -0700, Michael Torrie wrote:
> On Mon, 2004-02-16 at 05:33, Lionel Ulmer wrote:
> > > Seems like the best approach would be to write a special graphics driver
> > > for MS Windows that would translate gdi calls into X calls, allowing
> > > Windows windows to be displayed on the X desktop, with the Windows
> > > desktop hidden.  Eventually things like the system tray could be thunked
> > > to display icons in the Gnome/KDE tray area.  All in all, I think such a
> > > thing would be incredibly useful.
> > 
> > Well, this already exists : it's called Wine :-)
> 
> No, Wine is an attempt to implement the Windows API on linux.  What I've
> described has nothing to do with that.  Instead, you run Windows XP (the
> real version) inside of the qemu virtual  machine.  Then the special
> graphics driver pushes each window out to X11 (probably using the
> network, since that would require no changes to qemu).

Either you emulate Windows and have windows, or you don't emulate
Windows (which you suggest), and then you don't have windows to push
to X11. You can't have it both.

The hardware you want to emulate does not know the concept of 'a
window', and can -therefore- not emulate it.

-- 
Rutger Nijlunsing ---------------------------- rutger ed tux tmfweb nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------

Re: [Qemu-devel] Code Copy / New Linux boot code

[Gabriel Ebner]

Hello,

Am Mon, den 16.02.2004 schrieb Rutger Nijlunsing um 19:10:
> The hardware you want to emulate does not know the concept of 'a
> window', and can -therefore- not emulate it.

But it knows the concept of a network card over which you can transport
X11 with TCP/IP to the host.

It seems that the discussion gets so hot that you don't read the e-mails
anymore. :)

	Gabriel.

Re: [Qemu-devel] Code Copy / New Linux boot code

[Michael Torrie]

On Mon, 2004-02-16 at 11:10, Rutger Nijlunsing wrote:
> > No, Wine is an attempt to implement the Windows API on linux.  What I've
> > described has nothing to do with that.  Instead, you run Windows XP (the
> > real version) inside of the qemu virtual  machine.  Then the special
> > graphics driver pushes each window out to X11 (probably using the
> > network, since that would require no changes to qemu).
> 
> Either you emulate Windows and have windows, or you don't emulate
> Windows (which you suggest), and then you don't have windows to push
> to X11. You can't have it both.

You also misunderstand me.  Maybe I misunderstood what the parent poster
was talking about.

> 
> The hardware you want to emulate does not know the concept of 'a
> window', and can -therefore- not emulate it.

Precisely.  We're not talking about emulation at all here.  In fact,
what I was proposing is really outside the scope of qemu entirely, and
could be implemented with a real windows box running on some remote
machine.  All I was saying is that should such a driver system exist,
then combining that with qemu and a real copy of Windows XP would allow
a nice "rootless" environment where your real windows xp windows (MS
Word, etc) could appear on your X11 desktop.  I've been after Win4Lin
(www.netraverse.com) to implement something like this for years, but
they also seem to be mystified as to what I'm talking about.  If I had
the knowledge I needed to do this, I'd implement a prototype to show
everyone just how cool it could be (MS Word in an X11 window on
Linux/PPC, for example, running via emu and windows xp).  I guess
another way to think of it would be vnc displaying just arbitrary
windows from a remote server rather than the full desktop.  Again, this
has nothing to do with qemu at all, but rather qemu would is a nice
vehicle to make this type of thing possible.

Michael.
-- 
Michael Torrie <torriem@chem.byu.edu>

Re: [Qemu-devel] Code Copy / New Linux boot code

[Derrik Pates]

Michael Torrie wrote:
> Precisely.  We're not talking about emulation at all here.  In fact,
> what I was proposing is really outside the scope of qemu entirely, and
> could be implemented with a real windows box running on some remote
> machine.  All I was saying is that should such a driver system exist,
> then combining that with qemu and a real copy of Windows XP would allow
> a nice "rootless" environment where your real windows xp windows (MS
> Word, etc) could appear on your X11 desktop.  I've been after Win4Lin
> (www.netraverse.com) to implement something like this for years, but
> they also seem to be mystified as to what I'm talking about. 

I know exactly what you're talking about - like MacOS 9 apps on OS X, 
where the classic MacOS apps and OS X apps run in their own windows, 
rather than in a "virtual display". I've thought about doing this with 
Mac-on-Linux, but I'm not sufficiently familiar with the internals of 
QuickDraw and writing a MacOS display driver to make it work.

--
Derrik Pates
dpates@dsdk12.net

Re: [Qemu-devel] Code Copy / New Linux boot code

[Artur Skawina]

Michael Torrie wrote:
> what I was proposing is really outside the scope of qemu entirely, and
> could be implemented with a real windows box running on some remote
> machine.  All I was saying is that should such a driver system exist,
> then combining that with qemu and a real copy of Windows XP would allow
> a nice "rootless" environment where your real windows xp windows (MS
> Word, etc) could appear on your X11 desktop.  I've been after Win4Lin

http://xwinx.sourceforge.net/ seems close (i don't know about 
performance and the rootless mode).

Re: [Qemu-devel] Code Copy / New Linux boot code

[John R. Hogerhuis]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On Wed, 2004-03-03 at 06:58, Artur Skawina wrote:

> http://xwinx.sourceforge.net/ seems close (i don't know about 
> performance and the rootless mode).
> 

In the "Future" page the author describes the same thing
as "rootless mode" calling it "Citrix ICA® Style Published Apps"

The author appears interested in going that way but says
"Can anyone offer any advice on how to get a bitmap handle
 (HBITMAP) for a single Win32® window?"

But he may have figured that out since this page was written.

I assume there's some easy way to
do that. But I would think you'd want more than just the
bitmap, and actually want to know the invalid rectangles
and maybe the GDI calls for painting if you want
things to get really fast.

-- John.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] Code Copy / New Linux boot code

[Michael L Torrie]

On Fri, 2004-03-05 at 01:23, John R. Hogerhuis wrote:
> The author appears interested in going that way but says
> "Can anyone offer any advice on how to get a bitmap handle
>  (HBITMAP) for a single Win32® window?"

Sounds like the wrong way to go about it.  Citrix uses a special GDI
hook/graphics driver to retrieve the lower primitives, which is what you
would want in a rootless GDI to X11 bridge.

> 
> But he may have figured that out since this page was written.
> 
> I assume there's some easy way to
> do that. But I would think you'd want more than just the
> bitmap, and actually want to know the invalid rectangles
> and maybe the GDI calls for painting if you want
> things to get really fast.

Definitely.  I've never been impressed with VNC, other than that it
works everwhere on many platforms.

Michael


> 
> -- John.
> 
> 
> 
> ______________________________________________________________________
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
-- 
Michael L Torrie <torriem@chem.byu.edu>

Re: [Qemu-devel] Code Copy / New Linux boot code

[Lionel Ulmer]

> No, Wine is an attempt to implement the Windows API on linux.  What I've
> described has nothing to do with that.  Instead, you run Windows XP (the
> real version) inside of the qemu virtual  machine. 

Well, I perfectly understood what you meant and my post was more a joke then
anything else.. But well, if you take Wine's GDI implementation, it already
does exactly what you want : takes GDI commands and translate it into X11
commands (except that the interface is done at the GDI32 level and not at
the driver level as you would in your case).

And after, the more integration you want (copy paste, systray, ...) the more
DLLs you will have to thunk / rewrite and the more you will ressemble Wine :-)

But well, if it's feasable, it would really be a nice piece of work that
could even be used on real Windows to 'remote display' applications from a
real Windows box instead of an emulated one.

         Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Code Copy / New Linux boot code

[Michael Torrie]

My apologies for my post, then, and for my other post!  :)  I agree that
the usefulness of such a thing would extend far beyond Linux.

On Mon, 2004-02-16 at 13:17, Lionel Ulmer wrote:
> > No, Wine is an attempt to implement the Windows API on linux.  What I've
> > described has nothing to do with that.  Instead, you run Windows XP (the
> > real version) inside of the qemu virtual  machine. 
> 
> Well, I perfectly understood what you meant and my post was more a joke then
> anything else.. But well, if you take Wine's GDI implementation, it already
> does exactly what you want : takes GDI commands and translate it into X11
> commands (except that the interface is done at the GDI32 level and not at
> the driver level as you would in your case).
> 
> And after, the more integration you want (copy paste, systray, ...) the more
> DLLs you will have to thunk / rewrite and the more you will ressemble Wine :-)
> 
> But well, if it's feasable, it would really be a nice piece of work that
> could even be used on real Windows to 'remote display' applications from a
> real Windows box instead of an emulated one.
> 
>          Lionel
-- 
Michael Torrie <torriem@chem.byu.edu>

Re: [Qemu-devel] Code Copy / New Linux boot code

[Jamie Burns]

Well, whilst looking for some code examples for this kind of thing, I came
across:

http://ultravnc.sourceforge.net/

Which appears to be a version of VNC, which can export secific windows, and
is optimised heavily through use of Windows device driver hooks to be super
fast when sufficient bandwidth exists. On a local machine, it should be
plenty fast.

If nothing else, the concepts for hooking into GDI look interesting.

Thought that may be useful to those who thought it was an interesting idea.

Jamie.

----- Original Message ----- 
From: "Michael Torrie" <torriem@chem.byu.edu>
To: <qemu-devel@nongnu.org>
Sent: Monday, February 16, 2004 8:33 PM
Subject: Re: [Qemu-devel] Code Copy / New Linux boot code


> My apologies for my post, then, and for my other post!  :)  I agree that
> the usefulness of such a thing would extend far beyond Linux.
>
> On Mon, 2004-02-16 at 13:17, Lionel Ulmer wrote:
> > > No, Wine is an attempt to implement the Windows API on linux.  What
I've
> > > described has nothing to do with that.  Instead, you run Windows XP
(the
> > > real version) inside of the qemu virtual  machine.
> >
> > Well, I perfectly understood what you meant and my post was more a joke
then
> > anything else.. But well, if you take Wine's GDI implementation, it
already
> > does exactly what you want : takes GDI commands and translate it into
X11
> > commands (except that the interface is done at the GDI32 level and not
at
> > the driver level as you would in your case).
> >
> > And after, the more integration you want (copy paste, systray, ...) the
more
> > DLLs you will have to thunk / rewrite and the more you will ressemble
Wine :-)
> >
> > But well, if it's feasable, it would really be a nice piece of work that
> > could even be used on real Windows to 'remote display' applications from
a
> > real Windows box instead of an emulated one.
> >
> >          Lionel
> -- 
> Michael Torrie <torriem@chem.byu.edu>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Code Copy / New Linux boot code

[Michael Torrie]

Sweet.  Thanks for the tip.

On Mon, 2004-02-16 at 17:10, Jamie Burns wrote:
> Well, whilst looking for some code examples for this kind of thing, I came
> across:
> 
> http://ultravnc.sourceforge.net/
> 
> Which appears to be a version of VNC, which can export secific windows, and
> is optimised heavily through use of Windows device driver hooks to be super
> fast when sufficient bandwidth exists. On a local machine, it should be
> plenty fast.
> 
> If nothing else, the concepts for hooking into GDI look interesting.
> 
> Thought that may be useful to those who thought it was an interesting idea.
> 
> Jamie.
> 
> ----- Original Message ----- 
> From: "Michael Torrie" <torriem@chem.byu.edu>
> To: <qemu-devel@nongnu.org>
> Sent: Monday, February 16, 2004 8:33 PM
> Subject: Re: [Qemu-devel] Code Copy / New Linux boot code
> 
> 
> > My apologies for my post, then, and for my other post!  :)  I agree that
> > the usefulness of such a thing would extend far beyond Linux.
> >
> > On Mon, 2004-02-16 at 13:17, Lionel Ulmer wrote:
> > > > No, Wine is an attempt to implement the Windows API on linux.  What
> I've
> > > > described has nothing to do with that.  Instead, you run Windows XP
> (the
> > > > real version) inside of the qemu virtual  machine.
> > >
> > > Well, I perfectly understood what you meant and my post was more a joke
> then
> > > anything else.. But well, if you take Wine's GDI implementation, it
> already
> > > does exactly what you want : takes GDI commands and translate it into
> X11
> > > commands (except that the interface is done at the GDI32 level and not
> at
> > > the driver level as you would in your case).
> > >
> > > And after, the more integration you want (copy paste, systray, ...) the
> more
> > > DLLs you will have to thunk / rewrite and the more you will ressemble
> Wine :-)
> > >
> > > But well, if it's feasable, it would really be a nice piece of work that
> > > could even be used on real Windows to 'remote display' applications from
> a
> > > real Windows box instead of an emulated one.
> > >
> > >          Lionel
> > -- 
> > Michael Torrie <torriem@chem.byu.edu>
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
-- 
Michael Torrie <torriem@chem.byu.edu>