WineHQ
Wine Forums

Board index » WineHQ » Wine Help




 Page 1 of 1 [ 20 posts ] 



 
Author Message
 Post Posted: Thu Sep 22, 2011 3:01 pm 
Offline
Level 1
Level 1

Joined: Thu Sep 22, 2011 2:27 pm
Posts: 6
Greetings everyone. Let me start by stating that I appreciate the enormous undertaking that Wine has been, and I am not suggesting that the ideas I will ask about in this post would be easy (or even possible) to implement, so there's no need to flame the n00b.

As I understand it, Wine is an implementation of the Windows API for Linux and other Unix-like operating systems (Mac OS X, FreeBSD, Solaris, etc.). Wine is really super awesome, and can apparently even somehow run 16-bit in 64-bit versions of Linux despite the absence of Virtual 8086 mode while in Long Mode, something that 64-bit versions of Windows can't do. In my role as the webmaster and curator of a retro gaming website, I'm finding that a large number of older DirectX games don't run well in Windows 7. Windows just isn't very good at running old Windows software any more.

Before anyone tells me that I should switch to Linux or get a Mac for any of a thousand valid reasons, that would solve my problem, but it won't solve the problem for my visitors. Converting the world to Linux is a noble goal, but not one that I expect to be very successful at.

So, my question is whether it would be possible to make a portable version of Wine, perhaps using something like SDL. Actually, I see there are a number of ideas about how to run Wine on Windows (http://wiki.winehq.org/WineOnWindows), though it doesn't seem like any of them would work as well as a native Windows solution.

But, for that matter, why limit Wine to just Windows? ARM has jumped from smart phones to tablets, with netbooks on the way, and low powered notebooks planned in the future. Microsoft is even making an ARM version of Windows 8... which of course, won't run x86 Windows software. This "post PC world" thing might be for real. It seems like the only truly safe and universal platform is the web. danoon to the rescue, there is now a Java port of DOSBox called jDosbox, which has allowed me to make over 260 DOS games playable online at http://www.classicdosgames.com/online.html. jDosbox can even run Windows 3.x and Windows 98 -- though it would be illegal for me to install Windows in a disk image and put it online. Of course, there's HX DOS Extender. So the other question is, could Wine's implementation of the Windows API be incorporated into HX DOS Extender, and is there any interest in trying?

Anyway, I'm sure y'all are a friendly bunch, but go easy on me anyway. I realize that the purpose of Wine is to make life easier for Linux users, not to allow Windows programs to run on every operating system under the sun (including Windows), and I don't expect anyone to go out of their way to accommodate a userbase that the project was never intended to support.


Top 
 Post Posted: Thu Sep 22, 2011 3:41 pm 
Offline
Level 1
Level 1

Joined: Sun Sep 18, 2011 6:11 pm
Posts: 6
I just asked a similar question on porting Wine to other platforms. I would be interested in hearing any other info you get offline. I'm looking at SDL as a possibility.

Roger R. Cruz



On Sep 22, 2011, at 4:01 PM, "DOSGuy" <wineforum-user@winehq.org> wrote:

Quote:
Greetings everyone. Let me start by stating that I appreciate the enormous undertaking that Wine has been, and I am not suggesting that the ideas I will ask about in this post would be easy (or even possible) to implement, so there's no need to flame the n00b.

As I understand it, Wine is an implementation of the Windows API for Linux and other Unix-like operating systems (Mac OS X, FreeBSD, Solaris, etc.). Wine is really super awesome, and can apparently even somehow run 16-bit in 64-bit versions of Linux despite the absence of Virtual 8086 mode while in Long Mode, something that 64-bit versions of Windows can't do. In my role as the webmaster and curator of a retro gaming website, I'm finding that a large number of older DirectX games don't run well in Windows 7. Windows just isn't very good at running old Windows software any more.

Before anyone tells me that I should switch to Linux or get a Mac for any of a thousand valid reasons, that would solve my problem, but it won't solve the problem for my visitors. Converting the world to Linux is a noble goal, but not one that I expect to be very successful at.

So, my question is whether it would be possible to make a portable version of Wine, perhaps using something like SDL. Actually, I see there are a number of ideas about how to run Wine on Windows (http://wiki.winehq.org/WineOnWindows), though it doesn't seem like any of them would work as well as a native Windows solution.

But, for that matter, why limit Wine to just Windows? ARM has jumped from smart phones to tablets, with netbooks on the way, and low powered notebooks planned in the future. Microsoft is even making an ARM version of Windows 8... which of course, won't run x86 Windows software. This "post PC world" thing might be for real. It seems like the only truly safe and universal platform is the web. danoon to the rescue, there is now a Java port of DOSBox called jDosbox, which has allowed me to make over 260 DOS games playable online at http://www.classicdosgames.com/online.html. jDosbox can even run Windows 3.x and Windows 98 -- though it would be illegal for me to install Windows in a disk image and put it online. Of course, there's HX DOS Extender (http://www.japheth.de/HX.html). So the other question is, could Wine's implementation of the Windows API be incorporated into HX DOS Extender, and is there any interest in trying?

Anyway, I'm sure y'all are a friendly bunch, but go easy on me anyway. I realize that the purpose of Wine is to make life easier for Linux users, not to allow Windows programs to run on every operating system under the sun (including Windows), and I don't expect anyone to go out of their way to accommodate a userbase that the project was never intended to support.






Top 
 Post Posted: Thu Sep 22, 2011 9:41 pm 
Offline
Moderator
Moderator

Joined: Wed Apr 27, 2011 11:01 pm
Posts: 1153
On 9/22/11 1:01 PM, DOSGuy wrote:
Quote:
Greetings everyone. Let me start by stating that I appreciate the enormous undertaking that Wine has been, and I am not suggesting that the ideas I will ask about in this post would be easy (or even possible) to implement, so there's no need to flame the n00b.


There is an effort to port Wine to the ARM platform. The problem is
like that for the Mac PowerPC platform, you will need a CPU emulator
until Windows programs start to appear for the target platform. Given
the number of ARM based 'objects', this may not be too far off.
However, running an emulator AND a bloated Windows program may prove to
slow for ARM processors as it did for the PowerPC platform.

James


Top 
 Post subject:
 Post Posted: Sat Sep 24, 2011 6:45 am 
Offline
Level 8
Level 8

Joined: Fri Feb 29, 2008 2:54 am
Posts: 1020
DOSGuy First fact of the matter true win16 applications don't require virtual x86 mode at all.

Microsoft reason for removing win16 support is bogus basically. Dos support requires virtual x86 mode not win16.

http://sites.google.com/site/x32abi/ This is a true example of bending reality. 64 bit chips in long mode running 32 bit application code. Yes the same stunts to bend reality here can be done with 16 bit code running in protected mode as well. So yes win64 win32 and win16 all in theory could be run in long long mode. Currently wine is not exploiting this evil.

dos applications need emulation v86 is emulation of an old 8086 chip. Yes wine is working on using dosbox to fill that hole.

Making wine portable to non posix is basically a dream of fools almost. Reason is its not only X11 that is going to be trouble.

http://wiki.winehq.org/WineOnWindows This is only people who travelled down the tip of the iceberg. Samba and other parts are used by wine that are also suspect on non posix systems.

Arm and x86 emulations there are options to reduce pain but the problem is resources todo them. The means to run dll code native arm and application inside x86 emulation could reduce a lot of the performance bloat issue. Yes this would be a huge undertaking.

I am sorry DOSGuy end of days are basically coming up on people. If a lot goes to play by Microsoft and Hardware guys only place dos stuff will work is in emulation. So work on HX DOS Extender would mostly be a waste of resources since its never going to match what windows looks like internally.

Really wine is not that worry about windows. Reactos.org uses a large section of wine dlls for targeted goal of a Windows Replacement. Yes in a lot of ways working on the goal to replace windows with a clone is a simpler idea than running Wine inside windows or other non posix os designs. Since building a windows replacement you can use the windows subsystem design where as a independent developers you cannot use the subsystem design under normal windows unless stuff is signed and you don't duplicate with existing.

Before the Reactos developers started on reactos they did freewindows that is a long gone project that was basically a dos loader like HX DOS Extender they run into major issues to say the least. Reason for changing over to the NT design and starting clean. Basially working on HX extender is working on a path that is already known to lead to ruin.

DOSGuy you really need to start picking out the best games from dos and start cloning them.


Top 
 Post subject:
 Post Posted: Sat Sep 24, 2011 8:14 am 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
Quote:
But, for that matter, why limit Wine to just Windows? ARM has jumped from smart phones to tablets, with netbooks on the way, and low powered notebooks planned in the future. Microsoft is even making an ARM version of Windows 8... which of course, won't run x86 Windows software. This "post PC world" thing might be for real. It seems like the only truly safe and universal platform is the web.


I, and others, are hoping that the release of Windows for ARM will result in people making Windows/ARM programs that could work in an ARM WINE (no processor emulation). Then WINE on ARM stuff might be practical. Maybe even on a jailbroken iPhone or Android phone?

But as far as thinking that the only safe universal platform is the web...maybe. The beauty of compiled programming languages is that you can compile for whatever processor architecture/ operating system combo you want the program to run in/on. There are major exceptions, such as what WINE is facing. One can't simply take the WINE source code and compile it for Windows. But notice that even the same WINE source code can be compiled for several operating systems. I'm sure they had to be accounted for in the source code (quartz vs X, etc.), but with many simpler programs written in C, C++ and the like, they can be compiled for Mac, Windows, Linux...anything. I'm sure even for different architectures. You just have to have the compiler for what you want it to run on.

In many ways, C is a universal platform. Or D. Or C++. Except you aren't translating the program while you run it. It's translated once and ready to go. More efficient.

And then there's paravirtualization. You can have an operating system that flat out doesn't care about hardware.

What about online virtual machines or virtual machines up for download? If your audience isn't ready to switch or even dual boot with Linux, perhaps a downloadable virtual machine with WINE and some games already installed would be a good start. I seem to remember reading that VirtualBox doesn't support OpenGL, but if that's true, how can Linux function in it? I know that Zeckensack's wrapper disagrees with VirtualBox, though. Zeckensack's wrapper actually works in WINE. There is a build of QEMU that has OpenGL that might support Zeckensack's. And there's also VMGL.

Cheers,
Jake


Top 
 Post subject:
 Post Posted: Sun Sep 25, 2011 2:03 am 
Offline
Level 1
Level 1

Joined: Thu Sep 22, 2011 2:27 pm
Posts: 6
SpawnHappyJake wrote:
What about online virtual machines or virtual machines up for download? If your audience isn't ready to switch or even dual boot with Linux, perhaps a downloadable virtual machine with WINE and some games already installed would be a good start.


That's definitely an option I'm considering. I could offer downloads of virtual machines with Wine and one or more games pre-installed, but I might have to offer multiple downloads to cover all of the major emulators/virtualization suites, and it would still require my visitors to be savvy enough to know how to install and use an emulator/virtualization suite, and if they know how to do that, they could just as easily download the game and install it in a virtual machine themselves. What I'm planning for DOS games is to just pack a disk image with each game in a copy of jDosbox, since that will work on any platform that has Java. They just start jDosbox and a batch file starts the game for them. (Exactly that way I already do it on the online page.) It's simple, universal, and requires no technical knowledge on the part of my visitors.

I'm still searching for an equally elegant solution for Windows games. I haven't managed to get any Linux distro to run in DOSBox, which kills the Wine option. (I haven't had any luck getting anything to run in HX DOS Extender under DOSBox, though I haven't completely given up hope on that option.) I could install Linux and Wine in JPC (also a Java emulator), but JPC doesn't support sound, it's slow, and it just isn't very good yet. It looks like JPC development has ended in favor of JPC2, which appears to be a closed, probably commercial project.

I've used Wine in Ubuntu, so I know how awesome it is. That's why I dared to dream that Wine might be portable to a non-POSIX platform, or that Wine code might be used to improve HX DOS Extender. From what I'm reading, it looks like Wine depends on X11 and porting it to SDL didn't turn out so well. I don't begin to understand how Wine works or what would be involved in porting it beyond POSIX, so I really appreciate everyone's answers to my questions.


Top 
 Post subject:
 Post Posted: Sun Sep 25, 2011 6:08 am 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
One option is to run WINE in Ubuntu for Windows. There is actually a version of Ubuntu that runs in Windows as a Windows application. http://lifehacker.com/5195999/portable-ubuntu-runs-ubuntu-inside-windows

Another option is to provide USB stick images that could be applied by Self-Image. I suppose you could let them burn bootable ISOs. (to load Linux with WINE and games)

Have you been successful in running operating systems in DOSBox (other than DOS and booter games)?

The only reason why DOSBox even has the boot option is so that it can play booter floppies. DOSBox was never intended to be able to run Win95 or Win98 and most certainly not Linux.

I tried running Win98 in DOSBox, and it was almost worse than ReactOS (no offense ReactOS team, what you are doing is good). With 8 gigs of RAM and a quad-core 64-bit Intel processor, there was no excuse for it going as slow as it was, even with emulation. Unusably slow. Crashed at least half the time. I don't see how anyone can run games in Windows in DOSBox, let alone even Windows in DOSBox. Annoying to setup, too.

From my experience, trying to run any operating system in DOSBox is an absolutely terrible idea. DOSBox was not made for that. It was made for running DOS games and booter floppies. It has poor "virtual machine" functionality as far as hosting an OS, emulating a BIOS, mounting disk images, etc goes. It can't emulate an optical disk and use a cd image, can only mount two hard disks and one floppy image, can only use raw hard disk images, and is overall wonky and cumbersome. I don't even know if it's really emulating a BIOS.

Why must you think that no Linux in DOSBox = WINE is not an option? There has to be other ways. Either easy ways to run local virtual machines, or virtual machines that can be accessed online. Or the above mentioned WINE in Ubuntu in Windows trick.

Don't forget about paravirtualization to lighten the load, if you find something that supports that. Instead of the host and the guest using resources to worry about and handle hardware, and the having the load of emulating a virtual hardware platform, and the load of analyzing and intercepting and augmenting the exchange of data between guest kernel and processor, the guest OS just doesn't care about hardware, there is no emulated hardware platform, and you don't have to analyze, intercept, and augment data exchange between the kernel and processor.

Obviously virtualization (running a guest OS on the real processor) is much more preferable than running a guest operating system on a processor emulator (if possible). VirtualBox is open source, self-explanatory to use and install and you can even package virtual machines as VirtualBox "applications." There is VirtualBox for Windows, Mac, and of course, Linux. You can have VirtualBox applications up for download. Once downloaded, the user simply double-clicks the application file, and VirtualBox imports it. Sure, VirtualBox has to be installed first, but that's just clicking "next" a few times.

But if you absolutely must have emulation to run an OS, use something like QEMU or Bochs that was intended to be able to run operating systems. QEMU seems to be the standard, and its code is used in many softwares. The folks at OpenFirmware use QEMU to test their firmwares. I remember GRUB2 using it for something. I thing it was either for debugging or for BIOS emulation stuff. The Xen Hypervisor's hardware platform emulation for full virtulization is based on QEMU. It'd surprise you where QEMU finds you. But it just goes to show how trusted, stable, and fast it is.

QEMU is capable of both virtualization and emulation. It can mount hard drive, optical, and floppy images. You can pick the processor you want to emulate, if any, chose the BIOS image you want it to use, it lets you pick the graphics card you want to emulate, you can enable SDL, it does networking, and you can disable ACPI or HPET. But most importantly, it is quick and stable.

They're thinking about web access to VirtualBox virtual machines:[url]http://code.google.com/p/vboxweb/[url]

I remember reading that Google was working on making some web standard that basically let you use C in making web apps. You might be able to compile VirtualBox or QEMU or DOSBox for web before too long. Maybe I was thinking of Google Go. Thought there was one that fused C and HTML. Oh well. Maybe next week we can compile Gnu-style tarballs for web. Wouldn't that be nice?

Cheers,
Jake


Top 
 Post Posted: Sun Sep 25, 2011 2:29 pm 
Offline
Moderator
Moderator
User avatar

Joined: Sun Dec 07, 2008 8:33 am
Posts: 196
Location: Germany
jjmckenzie wrote:
On 9/22/11 1:01 PM, DOSGuy wrote:
Quote:
Greetings everyone. Let me start by stating that I appreciate the enormous undertaking that Wine has been, and I am not suggesting that the ideas I will ask about in this post would be easy (or even possible) to implement, so there's no need to flame the n00b.


There is an effort to port Wine to the ARM platform. The problem is
like that for the Mac PowerPC platform, you will need a CPU emulator
until Windows programs start to appear for the target platform. Given
the number of ARM based 'objects', this may not be too far off.
However, running an emulator AND a bloated Windows program may prove to
slow for ARM processors as it did for the PowerPC platform.

James


You don't fully know what you are talking about it seems.
Winelib is ported to ARM, just a few things missing but nothing critical.
The problem on PowerPC was mostly the endianess not the speed, further we see a faster ARM CPU every week. e.g. my handy has 1.2GHz dual core. There are chances

Quote:
I just asked a similar question on porting Wine to other platforms. I would be interested in hearing any other info you get offline. I'm looking at SDL as a possibility.

Roger R. Cruz

Why not post a link viewtopic.php?t=13533


Top 
 Post subject:
 Post Posted: Sun Sep 25, 2011 8:03 pm 
Offline
Level 8
Level 8

Joined: Fri Feb 29, 2008 2:54 am
Posts: 1020
SpawnHappyJake everyone forgets about qemu usermode emulation. One of the most advanced forms of paravirtualization.

Of course current qemu usermode emulation is limited. It emulates at the syscall to kernel point. So every time application does a syscall the syscall is processed natively.

To make wine more possible on arm expanding this usermode emulation would be required. Very much like x32 interfacing with 64 bit code. So that library calls inside qemu could be processed outside in platform native code. So reducing the performance damage from emulation even introducing AOT(ahead of time processing) instead of JIT that qemu uses could assist.

Arm and Modern PPC are both able to do either endlessness on demard. But you want these changes are low as possible.

SpawnHappyJake also Ubuntu inside windows is also not healthy you are losing good access to the video card.

Yes Winelib exists on arm as André H stated but but we have no way really to take full advantage of this fact when running x86 code on arm without qemu or equal having a major overhaul. Like even being able to add a set of custom syscalls that will be handled userspace on arm would be helpful. Ie do all the NT syscalls have them run arm returning to the x86 emulated user-space would help performance a little. Also this would add the means to call gate from the x86 code out to the arm version of Winelib. So reducing overheads of emulation since less x86 code would have to be emulated.


Top 
 Post subject:
 Post Posted: Mon Sep 26, 2011 2:25 am 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
Wow Oiaohm! That was a very interesting post. I'll have to mull it over a few more times. Not quite sure what you mean by a few things. By "qemu usermode emulation", do you mean that the entire QEMU emulator is running in user space, instead of kernel space, or do you mean that QEMU emulates a usermode?

When you say
Quote:
It emulates at the syscall to kernel point. So every time [an] application does a syscall the syscall is processed natively.
,
do you mean that an application running in the guest operating system passes a syscall to the guest "kernel," which is rigged to be a paravirtualized guest, then the special guest OS passes this application call to QEMU, which QEMU then passes to the host operating system to handle natively? So this "syscall to kernel point" emulation is only possible with paravirtualization?

If the guest is Linux, and the host is Windows, how can Windows answer Linux function calls from applications in the virtual machine? I think you must mean something different that what I'm thinking you meant.


One a different note in the same score, I Googled more on this Web code-Virtualization stuff. I found a PC emulator written in JavaScript: http://bellard.org/jslinux/. If you follow that link, you actually will load Linux in a tab in your wed browser! Pretty cool, huh?

As terrible of an idea as it might seem, I wondered if it is possible to convert C/ C++ source code into Java code. That is to compile for JVM instead of machine code. Then, assuming QEMU is written in C/ C++, one could run the source code through the converter and embed the code into a webpage, having QEMU online. Turns out that there is a C to Java converter. I wonder if the idea would work. Unorthodox enough?

Considering the WINE in Linux in Ubuntu idea, I was concerned about graphics. We need paravirtualization (period). We also need paravirtualization that renders on the real graphics card (as a specific subset). Running games in WINE in Linux in a PC emulator in a web browser in a host operating system when running the game on emulated graphics in the same amount of nesting is a fail. You need paravirtualization to send graphics calls to the graphics card.

Then I remembered WebGL. WebGL is based on OpenGL and is a library that extends....JavaScript! And we have already seen someone make a PC emulator in JavaScript. So, hopefully, it's not too much to ask for a JavaScript PC emulator/ virtualizer that has WebGL and paravirtualization. A virtual machine in such a hypervisor/ emulator could render games on the real graphics card. And a hard disk image with a paravirtual guest installed can theoretically be portable from one hypervisor to another in a better way than non-paravirtual guests can potentially be portable from one hypervisor to another, BTW.

It would be really groovy if we had a paravirtualization hypervisor embedded in a webpage that could detect the architecture of your processor, and based on that, determine if it has to emulate a processor or not. And furthermore it run off files and folders on your local hard drive that you may download, that it support WebGL, and that we have a Linux with the right modules inserted to run in this omnipresent VM. You don't even need those files and folders that make up the guest to be in a hard disk image because this is paravirtualization. Why waste resources emulating a hard drive? The hypervisor simply executes the kernel image like a supervisor executes a binary. WINE makes all graphics calls go to OpenGL, and that should marry just fine with WebGL. Then the game would render on your real graphics card. Might not want Compiz enabled, though :wink: .

It seems as though exporting syscalls from applications running in the VM to the host operating system, which would be useful in reducing code that has to go through a processor emulator (if emulating a processor), like Oiaohm was saying, is only possible if the host OS is Linux. But Oiaohm seemed to be saying that QEMU gets around that and has the host OS answer system calls anyways? Is QEMU a multi-platform reverse WINE?

Would it be better for an online hypervisor (that's almost type 3!) to be written in something like Google Go, rather than JavaScript? Either way, it's not a compiled language, so I don't see an efficiency gain in that regard.

So the last efficiency would be to have the user download and install a hypervisor for their machine code. But that would put us back at square one. Maybe the lesson here is that the Web isn't the only safe universal platform.

Cheers,
Jake


Top 
 Post subject:
 Post Posted: Mon Sep 26, 2011 2:41 am 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
Wait...maybe I'm starting to get it. Does QEMU have libraries to resolve syscalls of guests it supports for paravirtualization in order to resolve those syscalls without processor emulation? I think that might be what Oiaohm meant by:

Quote:
So that library calls inside qemu could be processed outside in platform native code ... Like even being able to add a set of custom syscalls that will be handled [in] userspace on arm would be helpful...


And that these libraries would need to be expanded for gaming in WINE in specialized Linux in an online hypervisor?

BTW, the Linux in the online PC Emulator worked well on my iPhone.

?,
Jake


Top 
 Post subject:
 Post Posted: Mon Sep 26, 2011 5:43 am 
Offline
Level 8
Level 8

Joined: Fri Feb 29, 2008 2:54 am
Posts: 1020
Currently Qemu userspace operation is that it receives a system call request from a contain Linux application. Arch convert the request and send it straight on to the native Linux kernel then does the same to the kernel answers.

Basically there is no guest kernel in qemu usermode emulation. Its the highest level of paravirtualization you can do. Ie no kernel and no devices emulated.

Now ideal for Wine case is instead of sending it on to Linux kernel but qemu to send it sideways to winelib for the native platform like arm or ppc from the windows x86 application running inside qemu usermode emulation.

Wine could use its own custom syscalls to call for operations processed outside in arm then have data returned to the virtualization.

Standard qemu usermode requires a OS match.

paravirtualization is a class of virtualizations. Part virtualizations. Part host. Qemu usermode is the most extrema form of Paravirtualization since you have done away with drivers and kernel of the OS by directly using the hosts kernel and drivers instead. So there is no guest kernel.

Most common paravirtualization only does away with a few drivers here and there.

http://wiki.qemu.org/download/qemu-doc. ... e-emulator This is the documentation on the usermode emulation SpawnHappyJake.


Top 
 Post subject:
 Post Posted: Mon Sep 26, 2011 12:05 pm 
Offline
Moderator
Moderator
User avatar

Joined: Sun Dec 07, 2008 8:33 am
Posts: 196
Location: Germany
if only qemu would already be able to do userspace emulation on Windows including the dlls...
that's mostly what we would need, we then could crosscompile qemu to Winelib/ARM and let it userspace emulate x86 and forward the calls wrt the arm dlls(.so)


Top 
 Post subject:
 Post Posted: Tue Sep 27, 2011 3:10 pm 
Offline
Level 1
Level 1

Joined: Thu Sep 22, 2011 2:27 pm
Posts: 6
SpawnHappyJake wrote:
One option is to run WINE in Ubuntu for Windows. There is actually a version of Ubuntu that runs in Windows as a Windows application. http://lifehacker.com/5195999/portable-ubuntu-runs-ubuntu-inside-windows


Very cool, but too large to bundle with downloads from my site.

SpawnHappyJake wrote:
Another option is to provide USB stick images that could be applied by Self-Image. I suppose you could let them burn bootable ISOs. (to load Linux with WINE and games)


If I was going to do that, it would have to be a super tiny Linux.

SpawnHappyJake wrote:
Have you been successful in running operating systems in DOSBox (other than DOS and booter games)?


Heck yeah! I run Windows 3.1 in DOSBox for all of my Win16 games, and it's absolutely flawless. Even WinG and Win32s work great. I haven't found anything that doesn't work perfectly under Windows 3.1 in DOSBox.

I also run Windows 95 in DOSBox for all of my Win9x games. I've only installed DirectX 6.1 so far, but that's been enough for every game I've tried so far. Whereas Windows 95 is virtually unusable under Bochs, Win95 runs at full speed under DOSBox. It's even faster than when I ran Windows 95 on a real computer back in the 90s. Using yhkwong's build, I set 4 MB of VRAM so that I can run Win95 at 1024x768 @ 32-bit color. Beautiful.

DOSBox also runs CP/M-86 almost flawlessly, but it refuses to let me format disks in CP/M format. Otherwise, it's almost as good as the real thing.

No luck with Win98 so far, and a FreeDOS hard drive image I created yesterday won't boot (which is weird, because MS-DOS, DR-DOS and FreeDOS boot floppies work fine), and absolutely no luck booting my ReactOS disk image. Still, it's pretty good for a program that's not supposed to run other operating systems.

SpawnHappyJake wrote:
Why must you think that no Linux in DOSBox = WINE is not an option?


I'm open to alternatives, but the point of a solution that works in DOSBox is to use jDosbox to make Windows games playable online.

SpawnHappyJake wrote:
But if you absolutely must have emulation to run an OS, use something like QEMU or Bochs that was intended to be able to run operating systems.


Bochs is a mixed bag. Some OSes won't work for me at all, and those that do are usually too slow to be useable. Still, it runs some older OSes better than Virtual PC and VirtualBox. There are only a few OSes I can stand to run in Bochs. As for QEMU, it was never user-friendly enough for me to get into it. It sounds like a good emulator, so maybe I'll try to set aside some time to learn it someday.

Thanks for the ideas!


Top 
 Post subject:
 Post Posted: Tue Sep 27, 2011 11:17 pm 
Offline
Level 1
Level 1

Joined: Tue Sep 27, 2011 11:08 pm
Posts: 5
As far as getting jDosbox to run a windows game without Windows I think the best bet will be to use ReactOS or Linux with WINE. I would bet it could be done with an image less than 100MB.

I have gotten jdosbox to boot a linux 2.4 kernel, but of course without ISA or PCI IDE hard drive support it doesn't get very far. Now that PCI is in Dosbox trunk hopefully it would be just a matter of time before someone comes up with a patch for PCI IDE. At that point I don't think it would be too hard to get linux fully up and running.


Top 
 Post subject:
 Post Posted: Wed Sep 28, 2011 10:15 am 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
Thanks for the good news. I'll have to try Win95 in DOSBox. I guess Win98 and DOSBox just don't mix. Also, one bummer is that DOSBox does not emulate MMX. I think QEMU and Bochs do. I haven't used Bocks, but I have used QEMU. And I had that terrible spell with Ykwhong's and Win98. Also, I had issues with DOS and FreeDos in DOSBox. I'll save those stories for later. Basically, fat16, no fat32. And that fixes things. But FreeDOS still couldn't run setup.exe. MSDOS could do things FreeDOS couldn't, and vise versa.

As far as QEMU not being user friendly... yeah. Yeah. Agreed. However, a bash script or batch file that runs a VM in QEMU for the user would be quite easy. And Windows has a pretty good GUI for it. At least it looked good online. Haven't used it myself.

Cheers,
Jake


Top 
 Post subject:
 Post Posted: Wed Sep 28, 2011 12:36 pm 
Offline
Moderator
Moderator
User avatar

Joined: Sun Dec 07, 2008 8:33 am
Posts: 196
Location: Germany
seems someone had already a solution for linux in dosbox:
http://bisqwit.iki.fi/source/linux-for-dosbox/
still don't see how that can run wine very well


Top 
 Post subject:
 Post Posted: Wed Sep 28, 2011 1:18 pm 
Offline
Level 1
Level 1

Joined: Thu Sep 22, 2011 2:27 pm
Posts: 6
SpawnHappyJake wrote:
Thanks for the good news. I'll have to try Win95 in DOSBox.


I tried for years to get my old copies of Windows 95 (B and C) to run in DOSBox, despite people posting videos of Win95 running happily in DOSBox. I finally got it working this year when I acquired a copy of the original release of Windows 95. Supposedly 95A also works, but I haven't tried it.

Even with the original release, I couldn't get through the installation process in DOSBox. I installed Windows 95 to a disk image in Bochs, then booted the disk image in DOSBox. I had to find a driver to get better than 640x480x16c graphics, and I had to tell Windows that it had a Sound Blaster 16, but once it was done, it was totally worth the effort. I keep a backup copy of a clean Windows 95 installation so that I never have to go through the installation process again.

I'm told that Windows 98 also runs in DOSBox, but my attempts to run a disk image with 98 SE on it goes nowhere. Again, I might need the original version. Warcraft III is the only game that has outright refused to run in Windows 95 (it pops up a notice saying you need Win98) so far, so it's probably not worth the effort of trying to get Win98 running in DOSBox if you can get Win95 running.

As for MMX, I'm not sure if any DOS game ever used MMX instructions, but if even one commercial DOS game did, that would probably justify adding MMX to DOSBox. They won't add stuff that's only for other OSes, but if you legitimately need a feature to run a DOS game, it should get a green light.


Top 
 Post subject:
 Post Posted: Wed Sep 28, 2011 6:58 pm 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
DOSBox is very well suited for playing DOS games. Probably actually better than using DOS. (get to pick processor speed...heck even the processor, and other stuff)

But let's visit the next couple generations of games. Let's say you want true 3DFX graphics card emulation. Meaning a 3DFX graphics card actually shows up in your list of hardware. The Ykwong subversion of DOSBox lets you do that, but there is no MMX, which I know at least Hype the Time Quest needs, and I'm sure lots of others do as well. Also, DOSBox does not emulate an optical drive. So how do you play games that have CD checks? Most kernel-level optical disc emulators for Windows will install into Win98, but not Win95. WinCDEmu is open source, and I wonder if it can be compiled for Win95. They say WinCDEmu can be compiled for Win 2000.

So Kekko's 3DFX emulation for DOSBox is great for DOS games that use 3DFX. And now that you are saying that you got Win98(A) running smoothly in DOSBox, there is hope for later games. And a cd emulator can be installed. And my joystick drivers can be installed (only go back to Win98, not Win95).

It's just too bad that Kekko's 3DFX emulator isn't implemented in VirtualBox or QEMU. Zeckensack's wrapper disagrees with VirtualBox. And a kernel-level 3DFX emulator would be super-sweet.

Old game incompatibility is like a submarine sandwich. DOSBox is nibbling at one end, and WINE is nibbling at the other.

Cheers


Top 
 Post subject:
 Post Posted: Thu Sep 29, 2011 9:01 am 
Offline
Level 1
Level 1

Joined: Thu Sep 22, 2011 2:27 pm
Posts: 6
SpawnHappyJake wrote:
Old game incompatibility is like a submarine sandwich. DOSBox is nibbling at one end, and WINE is nibbling at the other.


Maybe some convergence is indirectly possible. HX DOS Extender is open source and runs console Windows programs, and has partial support for GUI software. Presumably this is achieved through a DOS implementation of the Windows API. Perhaps Wine code could be used to improve HX DOS Extender's implementation?


Top 
Display posts from previous:  Sort by  
 
 Page 1 of 1 [ 20 posts ] 




Board index » WineHQ » Wine Help


Who is online

Users browsing this forum: No registered users and 23 guests

 
 

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: