[Qemu-devel] windows?

[Qemu-devel] windows?

[Mark IJbema]

Hi,

Sorry if this is a dumb question, but is there some architectural reason
qemu won't run on windows, or is it just not implemented?

Mark

Re: [Qemu-devel] windows?

[John R. Hogerhuis]

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

On Tue, 2004-02-24 at 15:26, Mark IJbema wrote:
> Sorry if this is a dumb question, but is there some architectural reason
> qemu won't run on windows, or is it just not implemented?

It would be a neat trick... maybe build with Mingw32

One application would be that if QEMU ran on Win32 you could put
QEMU.EXE on a Knoppix CD, and run Knoppix without the BIOS fiddling or
rebooting that might otherwise be required. CoLinux project has this
goal in mind too but I'm not sure how far along they are.

If someone wants help with such a scheme I have some spare cycles (and I
don't mind the taint of working on Windows as necessary)

-- John.



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

Re: [Qemu-devel] windows?

[dguinan]

I think the simple answer is lack of drivers.

-Daniel

On Feb 24, 2004, at 3:26 PM, Mark IJbema wrote:

> Hi,
>
> Sorry if this is a dumb question, but is there some architectural 
> reason
> qemu won't run on windows, or is it just not implemented?
>
> Mark
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] windows?

[Mark IJbema]

On Tue, Feb 24, 2004 at 03:44:36PM -0800, John R. Hogerhuis wrote:
> On Tue, 2004-02-24 at 15:26, Mark IJbema wrote:
> > Sorry if this is a dumb question, but is there some architectural reason
> > qemu won't run on windows, or is it just not implemented?
> 
> It would be a neat trick... maybe build with Mingw32
> 
> One application would be that if QEMU ran on Win32 you could put
> QEMU.EXE on a Knoppix CD, and run Knoppix without the BIOS fiddling or
> rebooting that might otherwise be required. CoLinux project has this
> goal in mind too but I'm not sure how far along they are.
> 
> If someone wants help with such a scheme I have some spare cycles (and I
> don't mind the taint of working on Windows as necessary)

Well, the application i had in mind was using it for reactos, in the
same way bochs is used now. Because on linux, qemu runs much faster than
bochs, and when it's bugfree (or at least not notably bugged), it would
be a viable alternative to vmware (even though it's still a lot slower
than vmware).

Mark

Re: [Qemu-devel] windows?

[Renzo Davoli]

On Wed, Feb 25, 2004 at 10:09:41AM +0100, Mark IJbema wrote:
> Well, the application i had in mind was using it for reactos, in the
> same way bochs is used now. Because on linux, qemu runs much faster than
> bochs, and when it's bugfree (or at least not notably bugged), it would
> be a viable alternative to vmware (even though it's still a lot slower
> than vmware).
> 
Even a lot safer (runs at user level, no kernel modules)
Even a lot general (runs already on four hardware architectures and this
number is the low boundary of what is going to be implemented in the
future).

It is not only an alternative to vmware, but also to VirtualPC and many
other virtual machine solution.
But it is also a general framework for running single executables for
the wrong architecture.
If you need to test proprietary sw and you have not the supported hw
architecture...
Say for example the flash plugin for mozilla/linuxppc. It is not
possible yet, but in the future maybe it will be possible through qemu
to join an heterogeneous plugin.

renzo

P.S. the real solution would be to convince everybody to leave
proprietary sw and formats, including flash. It needs time, though....

Re: [Qemu-devel] windows?

[Mark IJbema]

On Wed, Feb 25, 2004 at 10:21:20AM +0100, Renzo Davoli wrote:
> On Wed, Feb 25, 2004 at 10:09:41AM +0100, Mark IJbema wrote:
> > Well, the application i had in mind was using it for reactos, in the
> > same way bochs is used now. Because on linux, qemu runs much faster than
> > bochs, and when it's bugfree (or at least not notably bugged), it would
> > be a viable alternative to vmware (even though it's still a lot slower
> > than vmware).
> > 
> Even a lot safer (runs at user level, no kernel modules)
> Even a lot general (runs already on four hardware architectures and this
> number is the low boundary of what is going to be implemented in the
> future).

While this is true, i personally don't care, i only have x86 hardware
(though i should get some other hardware ;) )

> It is not only an alternative to vmware, but also to VirtualPC and many
> other virtual machine solution.
> But it is also a general framework for running single executables for
> the wrong architecture.

Yup, this could indeed be interesting for OS-es intended to run on
various hardware platforms, but for which most apps are released x86
only (WinNT / ReactOS).

> P.S. the real solution would be to convince everybody to leave
> proprietary sw and formats, including flash. It needs time, though....

Isn't flash open? I thought they released some sort of open Flash-XML
format...

Mark