QEMU Win95 screenshot

Hmm, can't send this directly to Fabrice Bellard.

I just thought you might like this screenshot.  I made a Micro95 install
with bochs, and tested it under qemu.  It works perfectly :)

Bravo on an excellent product.  It's soooo much faster than bochs ;)

http://gregorr.homelinux.org/qemu-win95.png

 - Gregory Richards

On 1 Mar 2004 06:11:48 -0000, MAILER-DAEMON <at> free.fr said:
> <fabrice DOT bellard AT free DOT fr>:
> User's Disk Quota Exceeded :
> Sorry, your message cannot be delivered as the recipient has exceeded
> their disk space limit for email.

--

-- 
http://www.fastmail.fm - A no graphics, no pop-ups email service

qemu-fast - a better howto?

Well, I managed to run normal Qemu, using a gentoo machine and my win98se cd

What I didnt manage is to compile qemu-fast

What about a some better howto about qemu-fast (how to set up, etc.)
and: does the kernel-configuration differ somehow with 2.6.x kernels?

I searched around on the qemu site, but didnt find anything detailed about it.

also, it is said, that I should look up at bochs for win98 graphics driver 
configuration. (win98 dont find any, VGA, SVGA and so on dont work)

but i didnt find any information about that on the bochs site (maybe i'm 
blind)

some links would be cool. ;)

-----
sorry for spammin'
g.g.

new code_copy code gives: error: storage size of `ldt' isn't known in helper2.c:97

Until recently I was able to build qemu-cvs but I updated today and now 
it gives an error:
/pub/projects/emulators/qemu/qemu-0.5.3-cvs/qemu/target-i386/helper2.c: 
In function `cpu_x86_init':
/pub/projects/emulators/qemu/qemu-0.5.3-cvs/qemu/target-i386/helper2.c:97: 
error: storage size of `ldt' isn't known
The problem is in the new code_copy code
helper2.c:94:
#ifdef USE_CODE_COPY
    /* testing code for code copy case */
    {
        struct modify_ldt_ldt_s ldt; //This is line 97

in target-i386/syscall.h the struct modify_ldt_ldt_s is defined:
target-i386/syscall.h:32:
struct target_modify_ldt_ldt_s {
    unsigned int  entry_number;
    target_ulong base_addr;
    unsigned int limit;
    unsigned int flags;
};

I can't see what the problem is.
Does anybody know?
Greetings,
Martin

./configure
Install prefix    /usr/local
Manual directory  /usr/local/share/man

Re: qemu-fast - a better howto?

Hello,

Am Montag, 1. März 2004 18:30 schrieb Gabriel Guzmics:
> What I didnt manage is to compile qemu-fast
Do you also get the following error?

gcc  -static -Wl,-T,/home/gebner/tmp/qemu/i386-vl.ld  -o qemu-fast vl.o 
block.o ide.o vga.o sb16.o dma.o oss.o fdc.o osdep.o sdl.o libqemu.a  -lm 
-L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthread -lm -ldl -lasound 
-L/usr/X11R6/lib -lX11 -lXext -laa -L/usr/lib -Wl,-rpath,/usr/lib -laa -lm 
-L/usr/X11R6/lib -lX11 -lslang
/usr/lib/libSDL.a(SDL_x11gl.lo)(.text+0x8d6): In function 
`X11_GL_LoadLibrary':
: warning: Using 'dlopen' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking
/usr/X11R6/lib/libX11.a(x11trans.o)(.text+0xfe0): In function 
`_X11TransSocketINETConnect':
: warning: Using 'getaddrinfo' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 
BFD 2.14.90.0.7 20031029 assertion fail elf.c:3460
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 
BFD 2.14.90.0.7 20031029 assertion fail elf.c:3460
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 
BFD 2.14.90.0.7 20031029 assertion fail elf.c:3460
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 
BFD 2.14.90.0.7 20031029 assertion fail elf.c:3460
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 
qemu-fast: Not enough room for program headers (allocated 5, need 7)
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 

Re: qemu-fast - a better howto?

 > What about a better howto about qemu-fast (how to set up, etc.)

I will update the documentation for the next release. My idea is to 
split it between user documentation and technical documentation.

I will also make a fix for the compilation of qemu-fast for the LDT problem.

The current state of qemu-fast in CVS is that it can only launch patched 
OSes, but at near native speeds (no precise benchmarks yet).

The specific "roadmap" for qemu-fast is:

- native floating point support (qemu-fast still uses full emulation for 
floating point, which is slow).

- faster self modifying code support (qemu-fast is slower than qemu on 
16 bit code which heavily uses self modifying code).

- faster memory mapped device access (qemu-fast is slower than qemu for 
VGA emulation).

- huge memory support (qemu-fast can simulate up to 256 MB of RAM, but 
this limit will be increased to 4 GB, and then 64 GB).

Fabrice.

[patch] linux 2.6 support

kernel 2.6 support
Change struct name in asm/ldt.h

_______________________________________________
Qemu-devel mailing list
Qemu-devel <at> nongnu.org
http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: Code Copy / New Linux boot code

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: Code Copy / New Linux boot code

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.

_______________________________________________
Qemu-devel mailing list
Qemu-devel <at> nongnu.org
http://mail.nongnu.org/mailman/listinfo/qemu-devel

Just a question - DX

I just was sitting at the loo when a thought pinged into my mind:
would be directX calls possible?

Just a question: If D3D calls would be passed to the graphics card by the 
virtual graphics driver, would that work?

One of the greatest disadvanteges of Linux for being Desktop Software is the 
missing implementation of DirectX (OpenGL on most cards is slower, too, like 
on my nVidia GeForce 5)

I dont know really if this could be solved anyhow without rewriting the whole 
DX-Core (like Wine does it) but maybe making DX runnable thru the virtual 
graphics driver? I dont know really how DirectX works, thats why I cant 
really tell if this thought is rather stupid, or not.

its just a question, note

Problem compiling qemu on Mandrake 9.2

I'm having quite a bit of trouble getting qemu to compile under Mandrake
9.2, and I think that the problem lies somewhere in the glibc library
that Mandrake uses and that qemu expects.

Whenever I try to compile qemu, I get the following error:

gcc  -static
-Wl,-T,/home/stealthdave/download/emulators/qemu/i386-vl.ld  -o
qemu-fast vl.o block.o ide.o vga.o sb16.o dma.o oss.o fdc.o osdep.o
sdl.o libqemu.a  -lm -L/usr/lib -lSDL -lpthread -lm -ldl -lasound
-laudio -lXt -L/usr/X11R6/lib -lX11 -lXext
/usr//bin/ld: cannot find -lm
collect2: ld returned 1 exit status
make[1]: *** [qemu-fast] Error 1
make[1]: Leaving directory `/mnt/data/download/emulators/qemu/i386'
make: *** [all] Error 1

I get the same error when trying to compile either 0.5.2 or current
cvs.  And it's not just the math library.  When I try to go in and edit
out the math library dependancy, it complains that it can't find
-lpthread, the next library in the list.  I have all the glibc and
glibc-devel packages installed.  Here's my glibc versions:

glibc-2.3.2-14mdk
glibc-devel-2.3.2-14mdk
libc-base-5.3.12-38mdk

I installed that last one to try and get qemu to compile.  Any help in
getting this to compile would be greatly appreciated.