Re: gtk [was Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window]
On Thu, May 26, 2005 at 04:32:52PM -0400, Jim C. Brown wrote: > Out of curiosity, would you accept an intergrated GUI for Linux if it was > based > on Xlib or an updated QtC (which was a Qt wrapper that enabled Qt to be used > in > C programs) ? > > The main advantage, that I can see, with using GTK is that you can run it on > the framebuffer (without X) - provided you have the proper GTK/GDK libs. > > > Fabrice. > > Just for the curious - I have written a patch for qemu so that you can GTK2 instead of SDL. Its not a full gui, only provides the functions that SDL does, and it is not stable yet (segfaults consistently when attempting to change the graphics mode). Email me privately if you wish to look at it. Once the code becomes stable, I do plan on abstracting it quite a bit more - eventually to the point where user can dynamically change GUIs. But that is far off. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Emulation problem with Embedded Visual Tool
Hi, I find impossibile to install the "Embedded Visual Tool" from Microsoft using latest QEMU (tested 0.7 and latest snapshot) and Windows 2000. Using QEMU+KQEMU bring an error during the first part of install, see image attached. It is in italian and following there is the translation: "Sottosistema Windows a 16 bit" -> "16 bit Windows Subsystem" "La CPU NTVDM ha riscontrato una exception non gestita" -> "CPU NTVDM encounters an unsupported exception" "Scegliere chiudi per terminare l'applicazione" -> "Choose Close to terminate the application". Dropping the KQEMU kernel module and performing again the installation with pure software emulation, emulation is better and only when installing SDK there is a problem during "Updating Registry", when the installation rollbacks. Trying to install the same Win2000 and the same "Embedded Visual Tool" on a real hardware, give no problem and installation went smooth. "Embedded Visual Tool" is available for free from Microsoft at the followin url: http://www.microsoft.com/downloads/details.aspx?familyid=f663bf48-31ee-4cbe-aac5-0affd5fb27dd&displaylang=en I hope someone can investigate this issue. Leandro <>___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: gtk [was Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window]
> SDL can also run directly inside a linux framebuffer :) > Qemu does work already with it. I tried a few months back. > But mouse and keyboard need tuning. And (Embedded) QT can also render to the framebuffer I believe. Don't know if that'll work with QtC, tho... Cheers, Mark > Christian > > > Out of curiosity, would you accept an intergrated GUI for Linux if it was > > based on Xlib or an updated QtC (which was a Qt wrapper that enabled Qt > > to be used in C programs) ? > > > > The main advantage, that I can see, with using GTK is that you can run it > > on the framebuffer (without X) - provided you have the proper GTK/GDK > > libs. > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: [PATCH] Embed QEmu screen on a custom window
> I've been trying to attach the QEmu screen to my frontend, but I > finally realized I needed to modify QEmu source to get it. > > So I've attached a patch that adds a "-hwnd " argument to QEmu. I've been pondering ways to wrap a Win32 gui (mostly likely written in Delphi or Python, no VB.dll) and thought a patch something like this would be helpful for managing multiple instances of QEMU similar in the way VMWare is able to manage multiple VM consoles in 1 tabbed control Window. So while I understand the inclination towards embedded gui's also... I think the more gui/management choices the better (spur innovation for a while)... So I'd like to offer my support for inclusion of Miguel's patch... for what it's worth... :) Cheers, -Garth -- Northern.CA ===-- http://www.northern.ca/ Canada's Search Engine ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
Christian MICHON wrote: Hi Fabrice, I understand your point clearly, and I still remembered it. But adding whichever toolkit would be adding pixels around the qemu instance, and it would have to interact with SDL. My simple logic here is why not do it in SDL itself, like an OSD you'd call by bindkey, like a TV remote control ? I do not know what cocoa.m implementation is, but I've seen screenshots. It does require space, and if you go full-screen, you can't do modifications. Hence the suggestion to go full SDL. I'll still look into the 4 SDL-guitoolkits I mentionned. Interesting stuff they can do... :) Improving the SDL interface is a waste of time as SDL has some annoying bugs and cannot give a good GUI for the end user. Doing a native GTK or Windows GUI is not complicated and would bring much more confort to the end user. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
On Thursday, May 26, 2005, 22:03:31, Fabrice Bellard wrote: > As I said earlier, I would prefer to integrate the GUI in QEMU like the > cocoa.m implementation. GTK for Linux is the best option. For Windows, > either GTK or a native GUI usage would be possible, depending on the > reliability of the GTK port for Windows. GTK+ on Windows is stable, and even though it doesn't officially support the Win98/ME anymore, it works on those OSes, too (recently, some bugs that prevented it working there were fixed; it doesn't work on Windows 95 though). -- < Jernej Simoncic ><><><><>< http://deepthought.ena.si/ > It won't work. -- Jenkinson's Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
Hi Fabrice, I understand your point clearly, and I still remembered it. But adding whichever toolkit would be adding pixels around the qemu instance, and it would have to interact with SDL. My simple logic here is why not do it in SDL itself, like an OSD you'd call by bindkey, like a TV remote control ? I do not know what cocoa.m implementation is, but I've seen screenshots. It does require space, and if you go full-screen, you can't do modifications. Hence the suggestion to go full SDL. I'll still look into the 4 SDL-guitoolkits I mentionned. Interesting stuff they can do... :) > As I said earlier, I would prefer to integrate the GUI in QEMU like the > cocoa.m implementation. GTK for Linux is the best option. For Windows, > either GTK or a native GUI usage would be possible, depending on the > reliability of the GTK port for Windows. > > Fabrice. > -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: gtk [was Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window]
SDL can also run directly inside a linux framebuffer :) Qemu does work already with it. I tried a few months back. But mouse and keyboard need tuning. Christian > Out of curiosity, would you accept an intergrated GUI for Linux if it was > based > on Xlib or an updated QtC (which was a Qt wrapper that enabled Qt to be used > in > C programs) ? > > The main advantage, that I can see, with using GTK is that you can run it on > the framebuffer (without X) - provided you have the proper GTK/GDK libs. > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
gtk [was Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window]
On Thu, May 26, 2005 at 10:03:31PM +0200, Fabrice Bellard wrote: > >this would pay more than to have 1 frontend for windows, 1 for linux, > >1 for sparc, 1 for mac, etc... > > > >what's your opinion on this ? > > As I said earlier, I would prefer to integrate the GUI in QEMU like the > cocoa.m implementation. GTK for Linux is the best option. Out of curiosity, would you accept an intergrated GUI for Linux if it was based on Xlib or an updated QtC (which was a Qt wrapper that enabled Qt to be used in C programs) ? The main advantage, that I can see, with using GTK is that you can run it on the framebuffer (without X) - provided you have the proper GTK/GDK libs. > Fabrice. > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
Christian MICHON wrote: yes, but this is only for windows hosts, and you must install visual basic. wouldnt' it be better to add an extra sdl "console" (today we've main window, control, serial, parallel) where we could set parameters graphically ? or at least as a text form to read a cfg file ? this would pay more than to have 1 frontend for windows, 1 for linux, 1 for sparc, 1 for mac, etc... what's your opinion on this ? As I said earlier, I would prefer to integrate the GUI in QEMU like the cocoa.m implementation. GTK for Linux is the best option. For Windows, either GTK or a native GUI usage would be possible, depending on the reliability of the GTK port for Windows. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
how much disk space is needed for qemu itself, and for a basic JRE. The size difference is around 30x to 50x. But I'll try the JQEMU tomorrow :) Christian On 5/26/05, Christian Bourque <[EMAIL PROTECTED]> wrote: > Christian MICHON wrote: > >this would pay more than to have 1 frontend for windows, 1 for linux, > >1 for sparc, 1 for mac, etc... > >what's your opinion on this ? > > You could also use my frontend JQEMU which works on any Java enabled platform > :) > > Christian > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU extension
On Thursday 26 May 2005 17:46, Mike Swanson wrote: > Though with KQEMU (for Linux and FreeBSD hosts only), you can run > x86-on-x86 emulation at native speed. Which is entirely irrelevant because: (a) You can't do the required instrumentation with a virtualization based solution like kqemu/qvm86. (b) kqemu is a closed-source binary released under a proprietary licence, so wouldn't be usable in a GPL project. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU extension
Though with KQEMU (for Linux and FreeBSD hosts only), you can run x86-on-x86 emulation at native speed. -- Mike ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU extension
On Thursday 26 May 2005 17:12, G Portokalidis wrote: > Hello, > > I'm writing concerning a possible use for qemu in a project related to > network security. > > I'm looking for an emulator where I could load an entire (recent) OS, > like Linux 2.6 or Windows XP and run multiple, potentially CPU > intensive, services (IIS, Apache, MySQL, etc). > > For the needs of the project I need to be able to know every instruction > executed by the guest OS, and run custom code whenever an instruction of > particular interest appears (doesn't really matter whether it's C or > x86, but preferably the first). > > So my first question is whether we could run Linux 2.6 and most > importantly Windows XP on qemu without stability issues. Linux works fine. For windows XP it seems to depend which windows version you're using. Some versions work ok, others don't. > Second, does > the current design of qemu allows me to implement the functionality > described in the above paragraph. You may be better using bochs. That has instrumentation hooks that should allow you do do what you want. boch is significantly slower that qemu, but if you're instrumenting a significant number of instructions it's going to be dog slow anyway. Qemu already has infrastructure for a gdb ICE connection. You could probably hack that to do what you want. > Finally, what's the performance of qemu compared with a PC (how many > times slower)? It's generally 10-15x slower than the host. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QEMU extension
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'm writing concerning a possible use for qemu in a project related to network security. I'm looking for an emulator where I could load an entire (recent) OS, like Linux 2.6 or Windows XP and run multiple, potentially CPU intensive, services (IIS, Apache, MySQL, etc). For the needs of the project I need to be able to know every instruction executed by the guest OS, and run custom code whenever an instruction of particular interest appears (doesn't really matter whether it's C or x86, but preferably the first). So my first question is whether we could run Linux 2.6 and most importantly Windows XP on qemu without stability issues. Second, does the current design of qemu allows me to implement the functionality described in the above paragraph. The developed code will be released under GPL and could be later incorporated in qemu if it provides commonly desired functionality. Finally, what's the performance of qemu compared with a PC (how many times slower)? Cheers, Georgios Portokalidis - -- Georgios Portokalidis Vrije Universiteit FEW, Department of Computer Science W&N, Room P471 De Boelelaan 1081a 1081 HV Amsterdam +31(0)20-5987726 VU-disclaimer: www.vu.nl/e-maildisclaimer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iEYEARECAAYFAkKV9X0ACgkQbZp0oqIQNPoi5wCeLqx4NWflCldTaOnywwp19+jG jWIAn3h2Kk0uCWS93IKP7pX33m+zj73q =mjLO -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] SPARC emulation using Debian
Hi, Perhaps the problem can be found with the help of source code, could you tell where to find the sources for the booting progam? Anyways, I suspect there are still a few bugs with context switching. _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] cocoa.m using openGL
Mike!Le 24 mai 05 à 17:11, Mike Kronenberg a écrit :[..]=> openGL is 3.5% faster on my systemImpressive ;)plus- it solves some issues i had with hiding/showing the toolbar (damaging the qd_view)- it could accelerate the generation of livethumbnails i am usingTestbuild and diff are onhttp://www.kberg.ch/cocoaqemuAt this point I'm asking, whether my patch should/can be included into the CVS, what changes I should make, or how to continue...Send your patch to Fabrice (and the list)! I can't really test it right now, but after a really quick look, it looks clean enough for me.And I don't think you should wait any longer. I think it is better to work directly on the CVS, with a patch per bug/features scheme.bye,Pierre.___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
Christian MICHON wrote: >this would pay more than to have 1 frontend for windows, 1 for linux, >1 for sparc, 1 for mac, etc... >what's your opinion on this ? You could also use my frontend JQEMU which works on any Java enabled platform :) Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] cocoa.m using openGL
Hi Peter, That is really great! To send your work: 1) download the cvs repository, see: http://savannah.nongnu.org/cvs/?group=qemu 2) send your diff: # cd /path/to/qemu # cvs diff -u cocoa.m > cocoapatch.diff.txt If you think your patch is clean enough, send it to Fabrice (and the list) so that it can be merged in qemu's repository. It seems that cocoa.m is under heavy work, which is good :) Pierre. Le 22 mai 05 à 15:00, Peter Stewart a écrit : Hello to all, esp. Pierre d'Herbemont, I have changed cocoa.m (0.7.0) to use openGL with very fast texturing. I removed the use of QuickDraw. The DisplayState data is now DMA'd to the graphics card instead of copied by the CPU. This uses apple's texture range extensions. The change means that the transfer of "display memory" incurs no CPU overhead. I also put in a bit more mouse stuff, and made some other fixes. I can't work out how to get the Window to get focus once it loses it, which is really a pain. I Shark'd it to make sure there wasn't any overhead from the texturing. I tested with Knoppix and FreeDOS. I am not sure if this is of interest to people, I just had a lazy weekend. I would like to give the code to the qemu project, but don't really know how to. thanks, peter. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
> I think Miguels patch is quite useful. It makes it possible to use > native Windows controls and Windows API calls to display a nice GUI for > Qemu, without adding much code to Qemu itself. Actually I've been > working on something similar for XFree (with XEmbed) to embed Qemu into > a GUI written with Perl and GTK :) (it partially works already, but > focusing and mouse grabbing doesn't work quite well yet). Btw. I > remember at least two people working on this XEmbed thing as well. > IMHO adding a GUI built with SDL would be much more difficult than using > native GUI toolkits. And doesn't the Cocoa patch aim at a native MacOsX > GUI in the end? All of these are very useful patches indeed. But there's at least 4 gui toolkit available for SDL, which could ensure: - a single developpement and a uniform look - no need for a bigger space on screen (the controls could be like OSD) - independent of hw/os architecture (the original aim somehow of qemu?) I agree this is poking inside qemu itself, which can be considered "a bad thing" (tm). I'm looking at the 4 gui toolkits I mentionned. - http://www.paragui.org/ - http://guichan.sourceforge.net/ - http://agar.csoft.org/index.html.en - http://aedgui.sourceforge.net/ Let's open the discussion in a separate thread. Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
Christian MICHON wrote: yes, but this is only for windows hosts, and you must install visual basic. wouldnt' it be better to add an extra sdl "console" (today we've main window, control, serial, parallel) where we could set parameters graphically ? or at least as a text form to read a cfg file ? this would pay more than to have 1 frontend for windows, 1 for linux, 1 for sparc, 1 for mac, etc... what's your opinion on this ? Christian On 5/26/05, Miguel Angel Fraile <[EMAIL PROTECTED]> wrote: Hi, I'm the author of QGui, a windows frontend for QEmu available at http://perso.wanadoo.es/comike. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel I think Miguels patch is quite useful. It makes it possible to use native Windows controls and Windows API calls to display a nice GUI for Qemu, without adding much code to Qemu itself. Actually I've been working on something similar for XFree (with XEmbed) to embed Qemu into a GUI written with Perl and GTK :) (it partially works already, but focusing and mouse grabbing doesn't work quite well yet). Btw. I remember at least two people working on this XEmbed thing as well. IMHO adding a GUI built with SDL would be much more difficult than using native GUI toolkits. And doesn't the Cocoa patch aim at a native MacOsX GUI in the end? However, the disadvantage of the "native GUI" approach might be that lots of different GUIs appear, instead of a graphical interface which is basically consistent on all platforms (like VMWare for Linux is basically consistent with VMWare for Windows, although both use different GUI toolkits). My conclusion is that there should be a discussion (or simply a decision) on how to build a GUI for Qemu, and that embedding Qemu into native GUIs could be a good way :) Oliver Gerlich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
yes, but this is only for windows hosts, and you must install visual basic. wouldnt' it be better to add an extra sdl "console" (today we've main window, control, serial, parallel) where we could set parameters graphically ? or at least as a text form to read a cfg file ? this would pay more than to have 1 frontend for windows, 1 for linux, 1 for sparc, 1 for mac, etc... what's your opinion on this ? Christian On 5/26/05, Miguel Angel Fraile <[EMAIL PROTECTED]> wrote: > Hi, > > I'm the author of QGui, a windows frontend for QEmu available at > http://perso.wanadoo.es/comike. > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Embed QEmu screen on a custom window
Hi,
I'm the author of QGui, a windows frontend for QEmu available at
http://perso.wanadoo.es/comike.
I've been trying to attach the QEmu screen to my frontend, but I
finally realized I needed to modify QEmu source to get it.
So I've attached a patch that adds a "-hwnd " argument to QEmu.
refers to the window handle where QEmu should be embedded (it
can be any control like a groupbox, form, etc).
Then, QEmu creates a new window that has the window specified at
command-line as parent. If QEmu screen size changes, parent and child
windows are resized automatically.
I hope the patch can be applied to CVS, as it would be very useful for
frontend authors.
PS: Please, add my mail address on CC, as I'm not subscribed to this list.
--- vl.c Thu May 26 11:04:04 2005
+++ vl.c.new Thu May 26 11:03:34 2005
@@ -150,6 +150,9 @@
#ifdef TARGET_I386
int win2k_install_hack = 0;
#endif
+#ifdef _WIN32
+HWND fend_hwnd, qemu_hwnd;
+#endif
/***/
/* x86 ISA bus support */
@@ -2785,6 +2788,9 @@
"-serial dev redirect the serial port to char device 'dev'\n"
"-parallel dev redirect the parallel port to char device 'dev'\n"
"-pidfile file Write PID to 'file'\n"
+#ifdef _WIN32
+ "-hwnd handle embed QEmu inside a custom window"
+#endif
"-S freeze CPU at startup (use 'c' to start
execution)\n"
"-s wait gdb connection to port %d\n"
"-p port change gdb connection port\n"
@@ -2883,6 +2889,7 @@
QEMU_OPTION_loadvm,
QEMU_OPTION_full_screen,
QEMU_OPTION_pidfile,
+ QEMU_OPTION_hwnd,
QEMU_OPTION_no_kqemu,
QEMU_OPTION_win2k_hack,
};
@@ -2953,6 +2960,9 @@
{ "loadvm", HAS_ARG, QEMU_OPTION_loadvm },
{ "full-screen", 0, QEMU_OPTION_full_screen },
{ "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
+#ifdef _WIN32
+ { "hwnd", HAS_ARG, QEMU_OPTION_hwnd },
+#endif
{ "win2k-hack", 0, QEMU_OPTION_win2k_hack },
/* temporary options */
@@ -3036,7 +3046,13 @@
char parallel_devices[MAX_PARALLEL_PORTS][128];
int parallel_device_index;
const char *loadvm = NULL;
-
+
+#ifdef _WIN32
+ char widbuf[24];
+ fend_hwnd=NULL;
+ qemu_hwnd=NULL;
+#endif
+
#if !defined(CONFIG_SOFTMMU)
/* we never want that malloc() uses mmap() */
mallopt(M_MMAP_THRESHOLD, 4096 * 1024);
@@ -3405,6 +3421,16 @@
case QEMU_OPTION_pidfile:
create_pidfile(optarg);
break;
+#ifdef _WIN32
+ case QEMU_OPTION_hwnd:
+ fend_hwnd=(HWND)atoi(optarg);
+ qemu_hwnd=CreateWindow("BUTTON",NULL,BS_OWNERDRAW | WS_CHILD |
+ WS_VISIBLE,0,0,700,420,fend_hwnd,NULL,
+ GetModuleHandle(NULL),NULL);
+ sprintf(widbuf,"SDL_WINDOWID=%#x",(long)qemu_hwnd);
+ putenv(widbuf);
+ break;
+#endif
#ifdef TARGET_I386
case QEMU_OPTION_win2k_hack:
win2k_install_hack = 1;
--- sdl.c Thu May 26 11:03:50 2005
+++ sdl.c.new Thu May 26 11:03:44 2005
@@ -27,6 +27,9 @@
#ifndef _WIN32
#include
+#else
+#include
+extern HWND fend_hwnd,qemu_hwnd;
#endif
static SDL_Surface *screen;
@@ -66,6 +69,12 @@
ds->depth = screen->format->BitsPerPixel;
ds->width = w;
ds->height = h;
+#ifdef _WIN32
+ SetWindowPos(qemu_hwnd,NULL,0,0,w,h,SWP_NOMOVE |
+ SWP_NOREPOSITION | SWP_NOZORDER);
+ SetWindowPos(fend_hwnd,NULL,0,0,w,h,SWP_NOMOVE |
+ SWP_NOREPOSITION | SWP_NOZORDER);
+#endif
}
/* generic keyboard conversion */
@@ -258,6 +267,9 @@
if (gui_grab) {
strcat(buf, " - Press Ctrl-Alt to exit grab");
}
+#ifdef _WIN32
+ if (qemu_hwnd!=NULL)
+#endif
SDL_WM_SetCaption(buf, "QEMU");
}
---
Best regards.
Míguel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] SPARC emulation using Debian
On Tue, May 24, 2005 at 09:49:03PM +0800, [EMAIL PROTECTED] wrote: > On Tue, May 24, 2005 at 02:41:07PM +0100, Tinnemeyer, Jorn wrote: > > Hello, > > > > I am trying to emulate a sparc system using Debian (kernel 2.6.8-2) > > > > with > > qemu 0.7.0. The installation fails during filesystem setup > > > > (output below). > > Does anyone have suggestion on how to proceed? > > > > > Kernel command line: root=/dev/rd/0 ro rw ramdisk_size=8192 rootfstype=ext2 > .. > > RAMDISK: Compressed image found at block 0 > > RAMDISK: incomplete write (-28 != 18432) 8388608 > > VFS: Mounted root (ext2 filesystem). > > Freeing unused kernel memory: 124k freed > > Setting up filesystem, please wait ... > > Setting up filesystem, please wait ... > > Kernel panic: Attempted to kill init! > > <0>Press L1-A to return to the boot prom > > try change ramesize=8192 to ramesize=16384 > sorry, try change ramdisk_size=8192 to ramdisk_size=16384 -- Hu Gang .-. /v\ // \\ Linux User /( )\ [204016] GPG Key ID ^^-^^ http://soulinfo.com/~hugang/hugang.asc Thank you for the advice. It corrected the loading of the ramdisk but the filesystem initialization is still having issues. Currently I am trying to reconstruct initrd to see what part is causing the problem. Joern Console: ttyS0 (SunZilog zs0) Using anticipatory io scheduler Floppy drive(s): fd0 is 1.44M FDC 0 is a S82078B RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize mice: PS/2 mouse device common for all mice input: Sun Type 5 keyboard on zs/serio0 i8042.c: i8042 controller self test timeout. NET: Registered protocol family 2 IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 32768) NET: Registered protocol family 1 NET: Registered protocol family 17 RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). VFS: Mounted root (ext2 filesystem). Trying to move old root to /initrd ... okay Freeing unused kernel memory: 124k freed Setting up filesystem, please wait ... ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
