[Qemu-devel] Makefile.target
Hi all, I've made a patch for OS X to use the built-in CD-ROM drive. (-cdrom /dev/cdrom). I used #ifdef COCOA_CONFIG in block.c and added -framework CoreFoundation -framework IOKit to COCOA_LIBS in makefile.target. This works ok. But I want the Patch to work with SDL, too. So I use #ifdef __APPLE__ in block.c. I tryed allot of thing but I'm no makefile hero :) So, how do I add the Frameworks now? Thanks Mike ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Notations about installing WinNT onto PREP hardware
Hi, I just installed WinNT 3.51 4.0 WKS to a PREP machine(Power Series Thinkpad). The first thing I had to do was installing ARC disk image to PREP 0x41 partition on HD. This Arc utility is then used for partitioning HD(Winnt PPC cant do this). And Winnt setup has to be launched from ARC menu too(run external program CD:\PPC\SETUPLDR). After installation ARC is also used to boot osloader.exe from a FAT partition of disk to run WinNT so on my opinion WinNT cannot be booted or installed before this ARC utility works under Qemu. You can Download this ARC image from ftp://ftp.software.ibm.com/pc/pccbbs/powerpc/arc151.dd Before booting this image under Qemu one should modify bootinfos.c from OHW to report machine model ie. IBM PPS Model 6050 instead of QEMU PPC. This image booting crashes shortly after going to Little-endian mode with followin: Invalid/unsupported opcode 00 - 10 - 01. Tero Kaarlela ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Monday, June 20, 2005, 3:59:11, Jim C. Brown wrote: I did find a GTK Windows tutorial at http://wolfpack.twu.net/docs/gtkwin32/, but that says to install the dlls to the System folder. Thanks to people like that I had to put detection of such broken installs to the GTK+ installer distributed on http://gimp-win.sf.net/ because we've had too many problems with Gimp not starting thanks to old GTK+ libraries in the PATH. -- Jernej Simoncic http://deepthought.ena.si/ If it does exist, it's out of date. -- Arnold's Second Law of Documentation ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tuesday, June 21, 2005, 4:27:04, [EMAIL PROTECTED] wrote: I'd rather keep them in the qemu directory. Just like I do with sdl.dll Semi-official place to put GTK+ libraries on Windows is C:\Program Files\Common Files\GTK\2.0, and then adding bin\ subdirectory to PATH. This is what GTK+ installers do by default. BTW, for compiling GTK+ programs, I set the PATH specifically for MSys so that my system-installed GTK+ doesn't interfere with the dev environment (also, this allows me to compile for a certain GTK+ version without configure complaining - GTK+ programs that are written for GTK+ 2.4 and earlier won't be able to open filenames containing non-ascii characters on Windows when compiled with GTK+ 2.6). -- Jernej Simoncic http://deepthought.ena.si/ Hot glass looks the same as cold glass. -- Cirino's Law of Burnt Fingers ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tuesday, June 21, 2005, 6:28:44, Jim C. Brown wrote: This is a particularly perplexing error, considering that a) this error should only show up if you 1) use a MSVC compiled GTK with a mingw/cygwin compiled app or 2) use a mingw/cygwin compiled GTK with a MSVC compiled app. Since you used mingw for both, I have not the slighest clue why this occurs. GTK+ and it's dependencies automatically specify -mms-bitfields when they're ocnfigured, so that you can use the same libraries for both MSVC and MinGW-compiled programs. -- Jernej Simoncic http://deepthought.ena.si/ Beauty times brains equals a constant. -- Beckhap's Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tuesday, June 21, 2005, 4:58:06, [EMAIL PROTECTED] wrote: No idea what it really means. Other than what it actually says. Do a export CFLAGS=$CFLAGS -mms-bitfields before configuring and compiling any GTK+ program on Windows - the libraries are always built to be compatible with MSVC so that you can use 1 set of libraries for all programs. -- Jernej Simoncic http://deepthought.ena.si/ The world is more complicated than most of our theories make it out to be. -- Berkeley's First Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tue, Jun 21, 2005 at 12:42:56PM +0200, Jernej Simon?i? wrote: On Tuesday, June 21, 2005, 4:58:06, [EMAIL PROTECTED] wrote: No idea what it really means. Other than what it actually says. Do a export CFLAGS=$CFLAGS -mms-bitfields before configuring and compiling any GTK+ program on Windows - the libraries are always built to be compatible with MSVC so that you can use 1 set of libraries for all programs. Aha. I wasn't aware of that ... so qemu was most likely built without -mms-bitfields. (I knew the option exists, but I didn't know it was the default.) I'll take a look at modifying the Makefile to support this. The world is more complicated than most of our theories make it out to be. -- Berkeley's First Law Indeed. -- 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] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)
Jim C. Brown wrote: I've been convinced. I'll take a look at it and see what can be done for a builtin ftp server. Hi Jim, Are there any results, yet? I'd like to help with testing this feature, as I cannot really help with coding. Jan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
This is a particularly perplexing error, considering that a) this error should only show up if you 1) use a MSVC compiled GTK with a mingw/cygwin compiled I downloaded the libraries and devel files from the link Jernej Simoncic recommended. It does seem to be a main win gtk distrib location. (As somebody pointed out, actually building gtk etc. under Mingw is a pita. I haven't tried, but judging from all the stuff that would be needed to build it, I suspect that's true.) The unzip into the proper mingw directory structure. Gtk Container period... other than GtkWindow.) There is also c) mixing GTK 2.2 and GTK 2.4 (or possibly GTK 2.4 and GTK 2.6) headers and libraries together (e.g. including the GTK 2.2 headers in qemu but using the GTK 2.4 libraries or something). I'm using the versions recommended and distributed on http://www.gimp.org/~tml/gimp/win32/ I get the same error regardless whether I'm using the recommended version or the bleeding edge version. It is possible that the 2 different mingw environments could have introduced incompatibilities (a very remote possibility). Perhaps recompiling GTK and its dependencies inside the new mingw environment would produce valid libraries. Or it might trash the new environment completely...*shrug* I don't know how to recompile all that stuff. I'm just downloading the pre-built devel libraries. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tuesday, June 21, 2005, 18:27:10, [EMAIL PROTECTED] wrote: I downloaded the libraries and devel files from the link Jernej Simoncic recommended. It does seem to be a main win gtk distrib location. (As somebody pointed out, actually building gtk etc. under Mingw is a pita. I haven't tried, but judging from all the stuff that would be needed to build it, I suspect that's true.) The unzip into the proper mingw directory structure. Did you unzip to /mingw or to /? If the latter, you'll probably have problems, since MSys expects that the executables in /bin use the MSys runtime, and it won't pass the command-line parameters properly. I get the same error regardless whether I'm using the recommended version or the bleeding edge version. Just adjust your CFLAGS to contain -mms-bitfields before configuring Qemu. -- Jernej Simoncic http://deepthought.ena.si/ No matter what goes wrong, it will probably look right. -- Scott's First Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tuesday, June 21, 2005, 18:30:07, [EMAIL PROTECTED] wrote: Do a export CFLAGS=$CFLAGS -mms-bitfields before configuring and compiling any GTK+ program on Windows - the libraries are always built to be compatible with MSVC so that you can use 1 set of libraries for all programs. I'll have to wait until Jim sends me the changes. I'm not a developer and I have no idea what you mean by export. Type export CFLAGS=$CFLAGS -mms-bitfields in MSys' bash before running ./configure (or simply add it to ~/.bashrc so you don't have to type it every time). Although the mingw/msys devel environment might work under Linux WINE, he wouldn't have any way to run test the resulting executables. MSys itself won't, since msys is actually stripped-down Cygwin. It is possible to cross-compile GTK+ programs from Linux (and it's definitely faster than under MSys, since bash+gcc are slow as hell on Win32; apparently, it's also almost easier to set up a cross-compilation environment in Linux than MSys on Windows for GTK+). -- Jernej Simoncic http://deepthought.ena.si/ The larger the project or job, the less time there is to do it. -- Old Engineer's Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
Jernej Simonèiè [EMAIL PROTECTED] The unzip into the proper mingw directory structure. Did you unzip to /mingw or to /? If the latter, you'll probably have Into the mingw directory. That part seems to compile etc. It's the resulting program that is screwed up some how. export CFLAGS=$CFLAGS -mms-bitfields Okay, I tried that. I then did a 'make clean'. Then the config, then the regular make But running the resulting qemu is still giving the same error. Considering how big the GTK libraries are for Windows, to be honest, I'm not so sure it's a good idea, anyway. The sdl library is only 300k and can be included with qemu. The gtk libraries are more than 6 meg and would be a little big to include with qemu. It just doesn't seem right to have the libraries being 8 times larger than the main program. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)
On Tue, Jun 21, 2005 at 04:17:08PM +0200, Jan Marten Simons wrote: Jim C. Brown wrote: I've been convinced. I'll take a look at it and see what can be done for a builtin ftp server. Hi Jim, Are there any results, yet? I'd like to help with testing this feature, as I cannot really help with coding. Jan Not a lot yet. I have a minimal ftp server that would be perfect to use with qemu, with much of the code rewritten. However, to make it interface with slirp a lot more work is needed (basicly the ftp server uses sockets while slirp works with tcp/ip packets directly. Thus I have to write a big interface layer (a sort of BSD sockets library on top of the slirp tcp/ip stack). The other approach that I've opted out of is to hack slirp to have support for the ftp protocol and run the server externally thru real sockets. If you or anyone else wants to try this, I'm willing to help a little. -- 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] quick gtk2.c update
On Tuesday, June 21, 2005, 21:40:26, [EMAIL PROTECTED] wrote: export CFLAGS=$CFLAGS -mms-bitfields Okay, I tried that. I then did a 'make clean'. Then the config, then the regular make But running the resulting qemu is still giving the same error. Hmm, it's been a while since I last tried compiling Qemu, but maybe you'll need to edit the makefiles to actually include that flag. Considering how big the GTK libraries are for Windows, to be honest, I'm not so sure it's a good idea, anyway. The sdl library is only 300k and can be included with qemu. The gtk libraries are more than 6 meg and would be a little big to include with qemu. It just doesn't seem right to have the libraries being 8 times larger than the main program. I'd say it's worth it, if Qemu gains a usable GUI this way. GTK+ libraries are ~3,5MB download, and only need to be installed once. -- Jernej Simoncic http://deepthought.ena.si/ Possessions increase to fill the space available for their storage. -- Ryan's Application of Parkinson's Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Building qemu on Sparc Solaris 9 or 10
I keep getting this with the standard file. [EMAIL PROTECTED] [ ~/qemu-0.7.0/] 138 sh configure configure: bad substitution [EMAIL PROTECTED] [ ~/qemu-0.7.0/] 139 When I take out the bsd magic since I only care about SVR4, I get a bunch of compile time errors. Any suggestions? Should I be using gmake? jonathan -- Jonathan R. KalbfeldNASA Jet Propulsion Laboratory MIST Support Engineer 4800 Oak Grove Drive M/S: 311-104 Sr. Member, ISCS Pasadena, CA 91109-8099 +1 818 393 0570 My opinions do not represent those of Caltech, JPL, NASA, or the US Government. If you feel you have received this message in error, please notify me, as I may have your e-mail address incorrectly recorded. Any e-mail sent to this address may at times be examined by any of the preceeding organizations, so please limit communications of a personal nature if you feel uncomfortable with a third party viewing those communications. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
Jernej Simonèiè Hmm, it's been a while since I last tried compiling Qemu, but maybe you'll need to edit the makefiles to actually include that flag. That's what I did. He sent me the patch to do that. It runs, but there are keyboard problems. The gtk libraries are more than 6 meg and would be a little big to include with qemu. It just doesn't seem right to have the libraries being 8 times larger than the main program. I'd say it's worth it, if Qemu gains a usable GUI this way. GTK+ libraries are ~3,5MB download, and only need to be installed once. Putting libraries like this in a common location is always a bad thing. That means the files whill have to be distributed with qemu And not everybody installs qemu over old versions, so you can't really expect the files to already be there from last time. It just seems fundamentally wrong to have a small emulator with very large libraries, just to satisfy some gui bloat. As for the gui... Well, I haven't seen that yet. What little I see looks the same boring Windows window that qemu always runs in. The gtk version isn't usable yet. I do like the idea of a gui... Really. I'm just saying that I think 6meg is a bit large for a program that's only 780k by itself. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)
On Tue, Jun 21, 2005 at 10:39:14PM +0100, Paul Brook wrote: Not a lot yet. I have a minimal ftp server that would be perfect to use with qemu, with much of the code rewritten. However, to make it interface with slirp a lot more work is needed (basicly the ftp server uses sockets while slirp works with tcp/ip packets directly. Thus I have to write a big interface layer (a sort of BSD sockets library on top of the slirp tcp/ip stack). Can't you just make the ftp code listen on a loopback socket, then use the normal slirp forwarding code? Paul Yes, as I said in my original email: The other approach that I've opted out of is to hack slirp to have support for the ftp protocol and run the server externally thru real sockets. If you or anyone else wants to try this, I'm willing to help a little. There is nothing wrong with using the slirp forwarding code (it would probably be a lot easier to get to work), I just think that its overkill to have to open a socket (rather, one for each data connection) on the host just so qemu can talk to itself. -- 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] quick gtk2.c update
On Tue, Jun 21, 2005 at 02:40:26PM -0500, [EMAIL PROTECTED] wrote: export CFLAGS=$CFLAGS -mms-bitfields Okay, I tried that. I then did a 'make clean'. Then the config, then the regular make But running the resulting qemu is still giving the same error. Not the slightest clue why that should be. Unless make or gcc was ignoring the CFLAGS variable (or you used different shells). You can try the Makefile.target patch I sent, that may give better results. Considering how big the GTK libraries are for Windows, to be honest, I'm not so sure it's a good idea, anyway. The sdl library is only 300k and can be included with qemu. The gtk libraries are more than 6 meg and would be a little big to include with qemu. It just doesn't seem right to have the libraries being 8 times larger than the main program. On Linux, the SDL library is 2.5M and the GTK library is 16.5M So I understand the feeling. However, if we can keep the Windows and Linux versions unified with GTK, I think that the benefit would be sigficant. -- 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] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)
Not a lot yet. I have a minimal ftp server that would be perfect to use with qemu, with much of the code rewritten. However, to make it interface with slirp a lot more work is needed (basicly the ftp server uses sockets while slirp works with tcp/ip packets directly. Thus I have to write a big interface layer (a sort of BSD sockets library on top of the slirp tcp/ip stack). Can't you just make the ftp code listen on a loopback socket, then use the normal slirp forwarding code? Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tue, Jun 21, 2005 at 04:19:33PM -0500, [EMAIL PROTECTED] wrote: I'd say it's worth it, if Qemu gains a usable GUI this way. GTK+ libraries are ~3,5MB download, and only need to be installed once. Putting libraries like this in a common location is always a bad thing. That means the files whill have to be distributed with qemu I disagree. I think distributing the GTK library with qemu (even for windows versions) is a very bad idea. At most, the qemu installer should just download and run the GTK installer. At most. GTK libraries are not part of qemu, they are a separate resource that qemu depends on. And not everybody installs qemu over old versions, so you can't really expect the files to already be there from last time. It just seems fundamentally wrong to have a small emulator with very large libraries, just to satisfy some gui bloat. I do like the idea of a gui... Really. I'm just saying that I think 6meg is a bit large for a program that's only 780k by itself. qemu is 3.4M here. So I don't think that is so bad. Especially when that one set of 6M libs can be shared by many different applications (qemu, xchat, etc). It is possible to rewrite the GTK code so it is only written in GDK (the only GTK object we use is the GtkWindow, which I guess could be replaced by a GdkWindow). GDK looks a lot smaller than GTK over here (4M vs 16M). As for the gui... Well, I haven't seen that yet. What little I see looks the same boring Windows window that qemu always runs in. The gtk version isn't usable yet. The GTK version, on Linux, is perfectly usable. It is no more usable than the SDL version, but no less. On Windows, you have no fullscreen support. Everything else should be exactly the same. If it's not, I'll try to fix it. A GUI is coming soon. I think. It runs, but there are keyboard problems. What keyboard problems? There shouldn't be any for the GTK version. -- 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] quick gtk2.c update
Jim C. Brown I disagree. I think distributing the GTK library with qemu (even for windows versions) is a very bad idea. At most, the qemu installer should just download and run the GTK installer. At most. It's a very bad idea to have the installer need to go back on to the net to download something else. The user should get the whole thing at once. GTK libraries are not part of qemu, they are a separate resource that qemu depends on. As far as the user is concerned, they are part of qemu. qemu is 3.4M here. So I don't think that is so bad. Especially when that one It shouldn't be. There isn't that much conceptually different between windows and linux that should cause it to be that big. set of 6M libs can be shared by many different applications (qemu, xchat, etc). Not under windows, it wont be. For us Windows users, qemu will be the only program we use that will need gtk libs. Realistically, we don't need GTK. We've already got a GUI with an api. That's what windows programmers use. The vast majority of us will never use xchat etc. Qemu may be the only one they use. And it's not a good idea to distribute the libraries seperately. Or put them in the Windows system directory. Too much junk gets put there already due to years and years of poor programming, careless authors, indifferent programmers, and Microsoft's encouragement. As for the gui... Well, I haven't seen that yet. What little I see looks the same boring Windows window that qemu always runs in. The gtk version isn't usable yet. The GTK version, on Linux, is perfectly usable. It is no more usable than the SDL version, but no less. But it's not usable on Windows yet. As I said, so far, I'm not seeing *any* gui. Even the keyboard is messed up, so you can't even use the guest OS. On Windows, you have no fullscreen support. Everything else should be exactly the same. If it's not, I'll try to fix it. I never use full screen, myself. I much prefer a window. Preferably one that's resizable, scroll bars, etc. etc. It runs, but there are keyboard problems. What keyboard problems? There shouldn't be any for the GTK version. As I said in the other message (which I may have accidently sent directly to you, instead of the list) It's not doing the regular US keyboard. At least it doesn't eappear to be. I can get symbols, a few letters, but not the whole thing. And none of it is normal. Press '1' to get 'n' and so on. However, it doesn't appear that the -k keyboard option works for the windows version. I tried my builds and the official 0.70 build and they don't accept it either. I tried -k fr -k de -k en-us and so on, and they don't recognise it. (I've never tried the -k option before, but according to the docs, it isn't needed for Windows builds. So it may not be enabled.) So, assuming the problem is that gtk can't recognise I'm using a US keyboard, I can't do anything to force it. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tue, Jun 21, 2005 at 05:45:12PM -0500, [EMAIL PROTECTED] wrote: GTK libraries are not part of qemu, they are a separate resource that qemu depends on. As far as the user is concerned, they are part of qemu. I must disagree here. If a user already has xchat 2 installed, and that person wants to try to use qemu with the GTK interface, they already have the libraries that they need. Including a set of GTK libraries just for qemu would not only be redundant in this case, it could potentially cause breakage to occur. I disagree. I think distributing the GTK library with qemu (even for windows versions) is a very bad idea. At most, the qemu installer should just download and run the GTK installer. At most. It's a very bad idea to have the installer need to go back on to the net to download something else. The user should get the whole thing at once. They should only get this library if they don't already have a copy installed. Of course there is a simple answer to this. Provide 3 qemu binaries for Windows: one that includes GTK support as well as the GTK libraries (so the installer can put them into the Common Files folder), one that includes GTK support but not the libraries, and one that has only SDL support. That's the dumb last resort option. Let's see who can come up with a smarter one. set of 6M libs can be shared by many different applications (qemu, xchat, etc). Not under windows, it wont be. For us Windows users, qemu will be the only program we use that will need gtk libs. Realistically, we don't need GTK. We've already got a GUI with an api. That's what windows programmers use. The vast majority of us will never use xchat etc. Qemu may be the only one they use. Ok, that is a valid point. I also agree that given what the GTK layer in qemu actually does, that is too much lot of overkill. (It would be really simple to just use pure GDK - the majority of the code is GDK.) However, I believe that the benefit of sharing the same GUI between Windows and Linux outweights this cost (esp. if what you say is true, that Windows builds are not very well maintained). And it's not a good idea to distribute the libraries seperately. Agreed. Or put them in the Windows system directory. Too much junk gets put there already due to years and years of poor programming, careless authors, indifferent programmers, and Microsoft's encouragement. I think the idea of using C:\Programing Files\Common Files\GTK 2.0 is a good solution for that. As for the gui... Well, I haven't seen that yet. What little I see looks the same boring Windows window that qemu always runs in. The gtk version isn't usable yet. The GTK version, on Linux, is perfectly usable. It is no more usable than the SDL version, but no less. But it's not usable on Windows yet. As I said, so far, I'm not seeing *any* gui. Even the keyboard is messed up, so you can't even use the guest OS. There is no GUI yet. I could easily make a crappy one in, say, 20 minutes. It'd work fine, but it may not be a lot of fun to use. For that matter, it may not be that useful. I'm waiting to hear from Fabrice and Sebastian for the GUI they have planned on top of the GTK layer. It seems that Fabrice is very picky when it comes to the GUI of choice for qemu. On Windows, you have no fullscreen support. Everything else should be exactly the same. If it's not, I'll try to fix it. I never use full screen, myself. I much prefer a window. Preferably one that's resizable, scroll bars, etc. etc. This isn't very difficult to do at all, and the code to do this for Linux and Windows should be identical. I'd like to fix the current bugs first though (on the off chance that there happens to be a difference on Windows that I don't know about). Once we fix those bugs, I'll look into making the qemu window resizable. It runs, but there are keyboard problems. What keyboard problems? There shouldn't be any for the GTK version. As I said in the other message (which I may have accidently sent directly to you, instead of the list) It's not doing the regular US keyboard. At least it doesn't eappear to be. It should. But it doesn't. Disturbing. I can get symbols, a few letters, but not the whole thing. And none of it is normal. Press '1' to get 'n' and so on. Yes, that is quite disgusting. However, it doesn't appear that the -k keyboard option works for the windows version. I tried my builds and the official 0.70 build and they don't accept it either. I tried -k fr -k de -k en-us and so on, and they don't recognise it. (I've never tried the -k option before, but according to the docs, it isn't needed for Windows builds. So it may not be enabled.) So, assuming the problem is that gtk can't recognise I'm using a US keyboard, I can't do anything to force it. Well, no, that isn't it. The keymap files are based on X11
Re: [Qemu-devel] quick gtk2.c update
Jim C. Brown I must disagree here. If a user already has xchat 2 installed, and that person wants to try to use qemu with the GTK interface, they already have the libraries that they need. Including a set of GTK libraries just for qemu would not only be redundant in this case, it could potentially cause breakage to occur. That's why you are supposed to put them in the directory of the app. It keeps from cluttering up the rest of the OS, possibly causing confusion, breakage, etc. with more than one version installed in various places (quite possible under windows) or having a damaged, broken one installed in the first place Windows looks. They should only get this library if they don't already have a copy installed. Which will be practically every qemu user. Of course there is a simple answer to this. Provide 3 qemu binaries for Windows: one that includes GTK support as well as the GTK libraries (so the installer can put them into the Common Files folder), one that includes GTK support but not Putting more stuff into the common files folders is just going to be 'clutter'. Things will never get used by any other application. Eventually the user will even entirely forget they are there. It just ends up being clutter. Or put them in the Windows system directory. Too much junk gets put there already due to years and years of poor programming, careless authors, indifferent programmers, and Microsoft's encouragement. I think the idea of using C:\Programing Files\Common Files\GTK 2.0 is a good solution for that. In theory. That's kind of what the directory is for. But that also assumes a few other things... Like those files actually might possibly ever get used by some other app. Not too likely for a Windows user. Second, by putting them in a common location, you open the possibility that they'll get replaced with newer versions. Which may not work right, if at all. That GTK website specifically mentions that certain versions are broken for Windows. By bundling the libraries with qemu, and keeping them in the qemu directory, you can guarantee that the user has versions that work right and are compatible with qemu. No -mms-whatever struct issue or anything else. However, none of that's really relevant, since at this point the gtk stuff doesn't even work under windows, so there's no point in distributing anything. There is no GUI yet. I could easily make a crappy one in, say, 20 minutes. It'd work fine, but it may not be a lot of fun to use. For that matter, it may not be that useful. Well, maybe not 'gui', but something that tells the user they are indeed running the GTK version and not the SDL version. It's not doing the regular US keyboard. At least it doesn't eappear to be. It should. But it doesn't. Disturbing. [shrug] All I can do is try to run it and report... I don't know qemu, gtk, or general mingw development to be able to say more. GetKeyboardLayout() or MakVirtualKeyEx(). What I really need is a Win32 programmer to proofread this, make sure I got it right. That would help They could help you debug this stuff. All I can do is try to compile it and run it. Not very helpful. Depending on how soon I can get to the patches you post, the test cycle may takes days for each event. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
